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A Copa do Mundo da FIFA chegou ao fim aqui 
no Brasil e, poucos dias após os fogos e a ani¬ 
mação do encerramento, chega para vocês, 
queridos leitores, esta nova edição da Jogos 80, a de 
número 13. No final de 2014, aliás, a revista comple¬ 
tará 10 anos de existência! 



Temos o imenso prazer de anunciar que, após 
muito tempo de busca, encontramos a pessoa respon¬ 
sável por converter o clássico jogo Karateka do Apple 
II para o TK2000, um ex-funcionário da softhouse na¬ 
cional Plan-Soft, o Sr. Luis Nakanishi. Não se trata de 


algo trivial, afinal, além da conversão do jogo pro¬ 
priamente dito, houve a adaptação de uma mídia para outra, ou seja, de diskette de 5,25" 
para fita cassete. Preparem-se, portanto, para conhecer um trabalho que certamente não foi 
fácil! 


Outra surpresa, desta vez para os fãs do ZX Spectmm, foi a visita que tivemos a honra e 
o prazer de realizar ao prédio em que a Sinclair Research funcionou em Cambridge, Ingla¬ 
terra, entre os anos de 1982 e 1985. O resultado da tour guiada - por um funcionário atual 
da instituição que ocupa o prédio - pode ser apreciado na forma de diversas fotografias e 
comentários feitos pelo enviado da Jogos 80 à Terra da Rainha, Marcus Garrett. 

Prosseguindo na série de artigos sobre Hacking no TK90X, o tradicional amigo e cola¬ 
borador Flávio Matsumoto preparou um especial muito interessante, em duas partes, sobre 
hacking dos programas em fitas cassetes. Outra novidade para os apreciadores de material 
mais técnico é a matéria acerca de uma nova ferramenta de programação para os micros 
da linha MSX, o Oldbits Dev Studio, escrita pelo também colaborador Ricardo Jurczyk Pinhei¬ 
ro. Ele entrevistou os criadores do software cuja promessa é facilitar bastante a criação de 
jogos e programas. 

Encerrando a edição, entre outras coisas, trazemos duas entrevistas internacionais. A 
primeira é a do britânico Andy Hopper, um dos colaboradores na criação do BBC Micro e na 
concepção da rede da Acorn, a Econet. O segundo entrevistado é Howard Scott Warshaw, o 
americano que programou o infame jogo de Atari "E.T. The Extra-Terrestrial", quem recente¬ 
mente esteve presente à alardeada escavação do famoso aterro, no Novo México, e contou 
para a Jogos 80 o que sentiu quando o primeiro cartucho viu a luz do dia, isto é, foi desenter¬ 
rado no mês de abril passado. 

Esperamos que se divirtam bastante com a leitura! 


Eduardo Luccas & Marcus Garrett 


dffliõ 




































Foto da época 


Marcus Vinícius Garrett Chiado 
Richard Atkinson 


E m Cambridge, Inglaterra, no prédio em que 
hoje funciona o departamento de T.I. (Tecno¬ 
logia da Informação) da universidade Anglia 
Ruskin, a Sinclair Research originalmente operou os 
setores de pesquisa/desenvolvimento, marketing e 
vendas entre os anos de 1982e 1985, época em que 
a empresa floresceu. Trata-se de um prédio muito 
bonito e que demonstra - e ecoa! - a visão de Sir 
Clive Sinclair, dono da companhia à época e empre¬ 
endedor britânico que, tamanho prestígio, acabou 
condecorado pela Rainha. 


A Jogos 80 foi convidada a visitar o 
local, que fica razoavelmente perto do fa¬ 
moso Trinity College de Cambridge, facul¬ 
dade frequentada por Sir Isaac Newton. O 
convite partiu do Sr. Joe Mclntyre, diretor- 
assistente da área de T.I., e lá estivemos eu 
e o amigo e colaborador Richard Atkinson 
no dia 8 de Maio. A oportunidade foi per¬ 
feita, já que também tivemos a chance de 
visitar o The Centre for Computing History 
(aguardem a Jogos 80 de dezembro), um 
museu de computadores localizado na 
mesma cidade. Joe, como insistiu em ser 
chamado, prestou-nos uma ótima visita 



guiada em que bastantes fotografias foram tiradas 
e muita informação foi repassada. 

Agora oferecemos a vocês, caros leitores, uma 
visita virtual para que possam ter um gostinho do 
Sinclair Research Building - e que, para tanto, não 
tenham de ir a Cambridge. Foi uma aventura e tan¬ 
to! 

O prédio: 

No comecinho dos anos 80, a Sinclair adqui¬ 
riu um prédio na 25 Willis Road, em Cambridge, e, 
pela primeira vez na história da empresa, todos os 
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“Sketch” encontrado durante reformas no prédio. 
Ele mostra possível lançamento futuro 










































departamentos foram reunidos 
em um só local. Anteriormen- 
te, naquele prédio, funcionaram 
uma engarrafadora de água mi¬ 
neral, a Barker & Wadsworth, e 
um armazém/depósito. A reforma 
para adequação realizada pela 
Sinclair, em 1981, foi uma impres¬ 
sionante demonstração da típica 
ousadia Sinclariana: havia, entre 
outras coisas, um lindo átrio ador¬ 
nado com enormes placas de 
metal, uma impressionante esca¬ 
da do tipo caracol, uma cobertu¬ 
ra envidraçada e um complicado 
sistema de aquecimento, tudo fei¬ 
to há mais de trinta anos. 

Ainda em 1981, a Sinclair 
Computers foi rebatizada de Sin¬ 
clair Research. O ZX81, micro ori¬ 
ginal cuja base foi usada para os 
nossos TK83, TK85 e CP200, pro¬ 


somente em 1982 (Wikipedia). Os 
lucros foram alavancados também 
devido à licença negociada com a Timex, 
que produziu o ZX81 nos Estados Unidos. A 
Sinclair expandiu bastante suas operações 
entre 1983 e 1984, tendo comercializado 
um número imenso de Spectrums. No ano 
de 1985, as vendas começaram a decair e 
o mercado para o modelo de 48 Kb decli¬ 
nou, o que causou o lançamento tardio do 
Spectmm 128 (primeiramente foi lançado na 
Espanha, pela Investronica, em 1985) na In¬ 
glaterra. O Spectrum+, embora ajudado no 
início por encomendas substanciais das ca¬ 
deias de lojas Dixons e W H Smith, terminou 
por não vender o esperado. 

Resumo da ópera: em dezembro de 
1985, Sir Clive precisou vender o prédio para 
o Conselho do Condado de Cambridgeshi- 
re por causa de problemas financeiros. Ele 
foi repassado, então, à universidade Anglia 
Ruskin, inicialmente sob um curto prazo es¬ 
tabelecido; prazo que acabou estendido, se- 
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Acima, entrada original maior; 
abaixo, entrada principal 


porcionou um lucro recorde para a 
empresa, de 8.55 milhões de libras 
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trum+, um modelo 48 que recebeu novo gabinete 
e novo teclado, em outubro de 1984 - com desen¬ 
volvimento igualmente na Willis Road. Interessante 
citar que muito provavelmente parte do desenvolvi¬ 
mento do infame veículo elétrico, o Sinclair C5, tam¬ 
bém aconteceu no prédio - Sir Clive, contudo, criou 
um braço empresarial para cuidar do C5, a Sinclair 
Vehicles Ltd, cuja operação foi levada à University 
of Warwick Science Park. Enfim, vários produtos fo¬ 
ram concebidos, testados e lançados na 25 Willis 
Road! 


Vamos conhecer o prédio? Então vamos! 


Acima: teto do Átrio; 
ao lado: porta rotatória do Átrio. 

gundo Joe, para 99 anos. O local, como 
a história demonstrou, viu dois momentos 
da empresa: forte ascensão e começo do 
fim. 

De todo modo, há muitas histórias fe¬ 
lizes. Novas tecnologias foram lá criadas, 
tais como o Microdrive lançado em 1983. 
O Sinclair QL, cujo lançamento, após mui¬ 
tos atrasos, aconteceu em janeiro de 1984 
sem que estivesse realmente pronto, foi 
outra das tecnologias desenvolvidas no 
prédio. O QL, aliás, não vendeu bem, era 
quase que uma tragédia anunciada devi¬ 
do ao pouco tempo de desenvolvimento. 
Na sequência, a Sinclair lançou o Spec- 
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Acima à esquerda: luxuoso acabamento do Átrio; acima à direita: famosa escadaria; 
abaixo à esquerda: parte de trás do prédio; abaixo à direita: porta de entrada de trás 
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A visitação: 

Trocamos e-mails com a universi¬ 
dade antes da visita e os detalhes foram 
acertados. Chegamos e fomos recebidos 
muito cordialmente pelo Sr. Mclntyre, um 
homem extremamente simpático. A visita 
começou pela entrada de trás do prédio, 
já que a porta frontal, do tipo giratório, não 
é usada por causa da falta de integração 
com o sistema de identificação/ponto ele¬ 
trônico - afinal, é uma porta giratória! Logo 
no início, vê-se um cartaz azul, muito boni¬ 
to, com os dizeres "Sinclair" e o logotipo da 
faculdade. Ao lado, há uma grande porta 
de vidro. Entramos por ela. 


Acima à esquerda: cobertura do prédio para festividades; 
acima: geradores que levavam calor; à esquerda, possível 

depósito da época da Sinclair. 


O Atrio: 

O Átrio, ou seja, o hall principal, à exceção do 
piso trocado (originalmente de difícil manutenção), 
está exatamente da forma como era na época 
da Sinclair. Parte das paredes são de tijolo e parte 
recebeu grandes painéis metálicos, o que propor- 
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ciona um visual impressionante. De cara, não é pos¬ 
sível deixar de notar a enorme escada do tipo Ca¬ 
racol, vermelha, cuja presença é incrível. A escada 
em questão, segundo Joe, é o objeto mais comenta¬ 
do pelos visitantes. Curiosidade: foi adicionado um 
corrimão, há alguns anos, por causa de crianças, 
filhos de funcionários da universidade que visitam o 
prédio de vez em quando. Não havia crianças nos 
anos oitenta. 

A cobertura do Átrio é feita de vidro em uma 
linda estrutura metalizada que fica ovalada. A en¬ 
trada principal acontecia por uma pesada porta 

À esquerda: cofre da época, ainda fechado e francado 
até hoje! Abaixo, copa da época; abaixo à esquerda: 
copa particular de Sir Clive Sinclair. 






















































aparelhos. 




Às salas superiores: 

Há diversas sa¬ 
las nos andares supe¬ 
riores. Infelizmente, o 
Sr. Mclntyre não tem 
certeza sobre o pos¬ 
sível uso original de 
algumas, então, adi¬ 
vinhação entra em 
jogo. Claro, podem ter 
alterado o uso de uma 
ou de mais salas com 
o tempo, é impossível 
ter certeza. Todavia, 


Acima: departamento de T.l. hoje; 
A direita: escritório de Sir Clive. 


giratória, que, se "dobrada" em duas partes, per¬ 
mitia o ingresso de caixas e pacotes de entre¬ 
gas. Conforme explicação de nosso anfitrião, o 
sistema de aquecimento do prédio era impressio¬ 
nante, usava o calor do porão (geradores) para 
esquentar o Átrio em um esquema de canos e 


A Universidade. 

A Anglia Ruskin University é uma universidade pública 
localizada no leste da Inglaterra, Reino Unido, com 
uma população estudantil estimada em 31.500 pesso¬ 
as. Os campi são localizados em Cambridge, Chelms- 
ford e Peterborough, todos no Reino Unido. 

A universidade foi fundada em 1858 por William John 
Beamont como a Cambridge School of Art, depois 
passou a ser chamada de Cambridgeshire College 
of Arts and Technology (CCATj em 1980. Em 1991 se 
transformou em uma faculdade politécnica, e em 
1992 ganhou status de Universidade. 

O University’s Student Services team ganhou reconhe¬ 
cimento, à época do Times Higher Education Awards 
201 2, de “o melhor do país". A faculdade gerou - e 
ainda gera - uma gama de profissionais reconhecidos 
no Reino Unido, tais como linguistas, jornalistas, escrito¬ 
res, geógrafos e outros. 

Fonte: WikiPedia 
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a primeira coisa que precisa ser dita é: na época da 
Sinclair, as salas tinham divisórias, as quais foram 
retiradas pela universidade. As salas são grandes 
lofts atualmente. 

Uma das primeiras salas, conforme explicação, 
parece ter sido usada para atendimento telefônico 
aos clientes, pois havia muitos cabos telefônicos nos 
rodapés e nas paredes. Na sala em questão, hoje 
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funciona - coincidência - o suporte técnico telefôni¬ 
co do departamento de T.I. Há uma pequena copa 
ao fundo que era usada como tal originalmente. Há, 
inclusive, um item que permaneceu da era Sinclair: 
um exaustor, náo mais em uso, instalado sobre uma 
área que abrigou um fogão. Eles o mantiveram! Vi¬ 
mos também outras salas, geralmente pequenas, 
cujo provável uso era a estocagem de produtos. 

Das salas, talvez a mais impressionante em ter¬ 
mos de curiosidade e de prestígio, é a que abrigava 
o escritório de Sir Clive em pessoa. Lá há um cofre 
que não é aberto desde a época! Sim, a universida¬ 
de não recebeu a combinação e tentaram conversar 
com ele, porém, sem sucesso. Imaginem o que pode 
haver lá! Tem-se cogitado, inclusive, a abertura do 
cofre à força, mas o procedimento ainda não foi fei¬ 
to. A verdade é que nem tudo está em uso. Há uma 
sala, teoricamente utilizada para desenvolvimento 
na época, que está em reformas, com fios saindo de 
todas as partes. Infelizmente, não obtivemos fotos, 
está tudo muito bagunçado. 

Final da visitação e Fachada Original: 


Algumas curiosidades: 

- No último andar há um terraço que, crê-se, era usado 
para confraternizações dos empregados. 

- Durante reforma recente, encontraram alguns cartuchos 
de Microdrive caídos atrás de um móvel. Encontraram tam¬ 
bém uma pintura em vidro que retrata um possível projeto 
da Sinclair. Vejam a foto na primeira página deste artigo. 
Não faz lembrar servidores? 

- Sir Clive bolou um sistema de projeção do tipo telão que, 
em tese, seria usado para demonstrações de novos pro¬ 
dutos, números de vendas etc., isto é, apresentações em 
geral. No meio da parede decorada com as chapas de 
metal, no Átrio, há uma chapa totalmente branca que se¬ 
ria usada como tela de projeção. O Sr. Mclntyre não tem 
certeza se o sistema funcionou alguma vez. 

- A universidade fechou o acesso aos prédios com grades. 
Não é mais possível entrar sem pedir autorização. 


construções metálicas da Sinclair e o prédio de ti¬ 
jolos da engarrafadora de água. Atualmente, tudo 
parece como na época, apenas o enorme logotipo 
da Sinclair foi retirado e guardado. 



Futuro do Prédio: 


Joe faz planos para que se crie um pequeno 
museu dedicado à Sinclair no prédio, um museu 

que provavelmente necessitará de doa¬ 
ções. Tudo está muito cru ainda, é qua¬ 
se como uma idéia somente, mas é algo 
que fatalmente acontecerá em um futu¬ 
ro próximo. 


Após a visitação interna, fomos levados à 
entrada original do prédio, a fachada. Interessan¬ 
te como o novo contrasta com o antigo, ou seja, as 


Esperamos que tenham gostado 
das fotos e das informações, não dei¬ 
xem de ler os boxes com as curiosida¬ 
des. Nós, que tivemos a chance de estar 
lá e que somos fãs da Sinclair, jamais 
esqueceremos! 
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Â esquerda , possivelmente local de 
atendimento telefônico. 












































ENTREVISTA: Luis Nakanishi 


K arateka sempre foi um jogo admirado e desejado 
por fãs do Apple II e, principalmente, por fãs de ou¬ 
tras linhas mais "humildes". Nem todos tinham sor¬ 
te - e dinheiro - para possuir um micro daqueles, caro e 
que costumava ser mais usado em escritórios, profissional¬ 
mente. Porém, graças a um programador dedicado de 
apenas 1 ó anos à época, os donos do bem mais simplório 
TK2000 também puderam ter a chance de lutar, no Ja¬ 
pão, contra vários oponentes e combater o malvado Aku- 
ma para que salvassem a princesa Mariko. Falamos de 
Luis Nakanishi, funcionário da Plan-Soft que, na ocasião, 
converteu Karateka a partir da versão original do Apple 
II, em diskette, para o TK - e para que carregasse de fita 
cassete. Um trabalho e tanto em uma época em que qua¬ 
se não havia documentação! Luis bateu um papo com a 
Jogos 80 e procurou se lembrar de vários detalhes sobre 
esta histórica conversão. 



Entrevista: Equipe Jogos 80 


Jogos 80: Sr. Nakanishi, é uma honra poder entre¬ 
vistá-lo. Primeiramente, conte aos nossos leitores 
sobre sua formação e seu trabalho. 

Luis Nakanishi: Depois que concluí meu curso técni¬ 
co de Eletrônica na Escola Técnica Federal de São 
Paulo, eu fui para o Japão e lá fiquei de 1990 a 1995. 
Foi a época em que usei muito a plataforma Ami¬ 
ga, da Commodore, para aprender sobre animação 
3D e processamento de imagens, mas nada profis¬ 
sional. Hoje trabalho como técnico de informática e 
estou terminando um curso de Tecnologia de Banco 
de Dados na Fatec de São José dos Campos. Traba¬ 
lho com manutenção de computadores e notebooks. 
Em relação à Plan-Soft, trabalhei na empresa por um 
ano apenas, eu tinha só uns 16 anos de idade. Se 
não me engano, foi em 1985. 

J80: Como foi que a oportunidade de converter 


Karateka para o TK2000 aconteceu? Tem idéia 
da quantidade de cópias vendidas? 

LN: Eu já vinha mexendo no jogo antes mesmo de 
entrar como programador júnior na Plan-Soft. Quan¬ 
do entrei na empresa, continuei o trabalho de adap¬ 
tar Karateka para uma versão comercialmente vi¬ 
ável em fita cassete. Como se sabe, originalmente 
ele era executado a partir de disquetes flexíveis de 
5,25". Em relação à comercialização, eu não tinha 
nenhuma informação do financeiro da empresa, 
portanto, não faço a menor idéia da quantidade de 
cópias vendidas. Imagino que tenha feito sucesso 
sim, uma vez que Karateka foi muito popular na 
plataforma Apple II. 

J80 : Usou-se o cartucho (interface) de disco 
do TK2000 para auxiliar no desenvolvimenfo da 
conversão? Talvez algum tipo de conexão (RS- 
232C)? 
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LN: Sim, claro, o Karateka original só rodava de dis¬ 
quetes. No início, o jogo foi adaptado na íntegra, isto 
é, em disco mesmo. A versão em fita cassete teve a 
3 a fase removida por motivo de limite no tamanho 
de arquivo para fitas. A adaptação para o cassete foi 
uma etapa posterior realizada já na Plan-Soft [Nota 
do Editor: A fase faltante é a do Calabouço. Após a 
grade, no TK2000 passa-se por salas vazias (no Apple 
há inimigos) até que se chega ao Akuma ]. 

J80: O sr. desenvolveu diretamente no TK2000 ou 
usou uma máquina 
de desenvolvimen¬ 
to como auxílio? Se 
sim, qual a configu¬ 
ração da máqui¬ 
na? 

LN: Não, tudo foi feito 
apenas no TK2000. 

J80: Quais ferra¬ 
mentas de de¬ 
senvolvimento o sr. usou (Editor, montador ASM, 
etc)? 

LN: Usei apenas o próprio mini-Assembler do TK2000 
e uma ferramenta muito simples, escrita em Assem- 
bly, que se chamava "Find". Eu a usava para buscar 
sequências especificas de bytes no código. Era útil 
quando precisava encontrar textos dentro do pro¬ 
grama ou qualquer referência a endereços especí¬ 
ficos de memória. 

J80: Na época da conversão, o TK2000 de 128 Kb 
já estava no mercado? Chegou-se a considerar 
a possibilidade de uma conversão “estendida" 
para ele? 

LN: No momento não consigo me lembrar destes de¬ 
talhes, mas acredito que, mesmo tendo mais memó¬ 
ria, ainda haveria o limite de tamanho imposto pelo 
sistema de arquivos em fita. 

J80: Podemos imaginar o tremendo trabalho que 
foi adaptar um jogo imenso de disco para fita 
cassete. Conte aos nossos leitores sobre como 


foi o processo de ‘desmanchar’ o Karateka e 
remontá-lo em um formato que pudesse ser lido 
de cassete. 

LN: O trabalho maior foi conhecer toda a arquite¬ 
tura do jogo. Fui muito a fundo, conhecia bem os 
blocos de memória responsáveis por cada função, 
isto é, onde ficava o código responsável pela intro¬ 
dução, pela I a , 2 a , 3 a e 4 a fases etc. Consegui inclu¬ 
sive descobrir alguns endereços de memória que, 
quando alterados seus valores, faziam com que os 

oponentes ficassem 
imóveis (muito útil 
para testar rapida¬ 
mente as fases sem 
precisar jogar "real¬ 
mente"), uma espé¬ 
cie de hacking. Só 
não me perguntem 
como descobri, pois 
não faço a mínima 
idéia. Cada fase era 
carregada do disco 
na mesma posição de memória, e com um progra¬ 
ma em linguagem de máquina, eu consegui isolar 
cada bloco para poder trabalhar na adaptação 
para o TK2000. 

J80: A rotina de leitura de teclado publicada no 
Manual Técnico do TK2000 é, falemos a verda¬ 
de, uma tragédia em termos de performance. 
Como o sr. lidou com o problema da leitura do 
teclado? 

LN: Sim, concordo. Algumas referências técnicas 
daquele manual eram meio confusas, mas consegui 
destrinchá-lo e ele me ajudou bastante nos primei¬ 
ros conhecimentos de base para adaptar software 
do Apple II. Conseguia até fazer instmções do tipo 
"Pressione Shift para Continuar", coisa que no Apple 
II nunca foi possível. Se não me falha a memória, 
usei isso no simulador de vôo do TK2000. 

J80: Poderia comentar sobre esse simulador? Se¬ 
ria o subLOGIC Flight Simulator? 

LN: Sobre o simulador, não tenho quase nada a di- 
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. .no início, o jogo foi adaptado naíntegra, 
isto é, em disco mesmo. A versão em íita 
cassete teve a 3 a fase removida por moti¬ 
vo de limite no tamanho de arquivo para 
fitas. A adaptação para o cassete foi uma 
etapa posterior realizada já na Plan-Soft...” 
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zer, nem me lembro direito. Era uma conversão do 
Apple II, porém, não me lembro da empresa que fez 
o jogo original. 

J80: Alguma outra diferença de hardware do 
TK2000 apresentou dificuldades no desenvolvi¬ 
mento da conversão (excetuando-se, obviamen¬ 
te, o endereço da HGR2 em $A000)? 

LN: Os maiores desafios de uma adaptação do Ap¬ 
ple para o TK2000 eram justamente o teclado e os 
endereços de memória de vídeo. Sem dizer que o 
Apple contava com um gerador de caracteres para 
texto e áreas de memória específicas para isso, en¬ 
quanto no TK2000 era tudo gráfico, desenhado pixel 
a pixel, para gerar os textos. Felizmente, ao que me 
recordo pelo menos, o Karateka tinha um sistema 
de renderização gráfica unificada, que facilitou bas¬ 
tante o processo de adaptação gráfica, pois foi só 
alterar os acessos à segunda página gráfica para o 
endereço correto ($A000; 
no Apple, se não me en¬ 
gano, era $4000) nesse 
módulo do jogo. 


que me recordo é o simulador de vôo que citei aci¬ 
ma, pena que não me lembro do nome. 

J80: 0 sr. sabia que entre as softhouses brasileiras 
da época havia “apropriação indevida’’? Exem¬ 
plo: o “Sabotagem’’ que foi convertido pelo pes¬ 
soal da Multisoft. A SoftKristian simplesmente o 
renomeou para “Contra Ataque" e manteve o 
binário tal qual (com o nome de quem o conver¬ 
teu escondido no próprio binário). 

LN: Não soube de nenhum caso assim na época. 
Mas confesso que havia uma proteção no Karateka 
que verificava se os créditos do jogo haviam sido 
alterados. Em caso afirmativo, ele apagava toda a 
memória residente. Temos que proteger nosso esfor¬ 
ço, não é mesmo? 

J80: Gostaríamos de saber das relações entre 
as softhouses. O sr. tinha contato com o pesso- > 


J80: Já se sabia, na 
época, que o TK2000 
era um clone do MPF- 
II? Houve algum apoio 
da Microdigital nas 
conversões da Plan- 
Soft? 

LN: Não sei dizer. Não, 
foi um trabalho inde¬ 
pendente. 

J80: Quais outros jo¬ 
gos/aplicativos tive¬ 
ram sua participação 
na Plan-Soft? E fora 
dela? 

LN: Puxa, eu realmen¬ 
te não me lembro, só fiz 
jogos comerciais pela 
Plan-Soft. O único de 


PLAN SOFT 


s 

* 

o 

H 



À esquerda, a capinha do estojo da fita 
cassete do jogo e, mais abaixo, a fita pro¬ 
priamente dita, como era comercializada 
à época; abaixo o pequeno manual de 
instruções que acompanhava o jogo. 


KARATEKA 508 


KARATEKA 508 


PLANSOFT 




KARATEKA 508 

Fabricado por Fonobràs. Distribuidora Fonográfica Brasileira Ltda CGC 29 010.519/0001 32 


CARREGAMENTO: 

Este programa está gravado em duas partes. 
Apresentação e jogo. Para carregá-lo digite "LOADT". 
Ao se iniciar a Apresentação, ou seja quando aparecer 
na tela "PLANSOFT APRESENTA", desligue o 
gravador. Se voce quiser passar pela Apresentação e ir 
direto ao jogo, digite Barra de Espaço sem desligar 
o gravador e o jogo será carregado. 

- TECLAS DE COMANDO MODO DE LUTA: 

Barra: - Iniciar modo de luta 

- Após vencer inimigo p/ 
posicionar o lutador para corrida 
Seta Direita: Iniciar corrida 

Seta Esquerda: Para parar 

MODO DE ATAQUE 

Seta Direita: Avançar 

Seta Esquerda: Recuar 

Q: Soco p/ cima 

A: Soco central 

Z: Soco p/ baixo 

W: Chute p/ cima 

S: Chute central 

X: Chute p/ baixo 

0BS:_Se voce tiver interface de 
drive, desconecte-a. 
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al de outras empresas “concorrentes”, tais como 
Armando Neves (SoftKristian), Aroldo P. C. (Ciber- 
tronj, Rene 8. M. Junior (Cibertron) e Luiz A. Seg- 
ger (Multisoft)? 

LN: Destes nomes, apenas o Rene (embora não me 
lembre do nome da empresa) era meu amigo pes¬ 
soal, trocávamos muitas informações técnicas, mas 
sempre tivemos muita ética. Ele não interferiu nem 
usou meus jogos em desenvolvimento na Plan-Soft 
ou vice-versa. Ele acompanhou todo o desenvolvi¬ 
mento do Karateka. Uma vez, ele até foi me visitar 
na Plan-Soft, passando a tarde comigo lá, o que me 
custou um puxão de orelhas do meu chefe (que, 
claro, zelava pela confidencialidade dos projetos 
desenvolvidos). O Rene percebeu e não apareceu 
mais lá... 

J80: 0 sr. participou da conversão do jogo Grand 
Pr/x em que traduziram Suécia como Suíça ? 

LN: Não que eu me lembre. Mas eu acho que, na 
época, já sabia a diferença entre Sweden e Swiss. 

J80: Muito obrigado pela entrevista! 

LN: Eu que agradeço. 


Agradecemos aos amigos Carlos Bragatto, Lisias To¬ 
ledo e Georg Bahr Julião pelas sugestões de pergun¬ 
tas enviadas. 


Embora não se lembre direito, Luis Nakanishi tam¬ 
bém teria convertido do Apple II para o TK2000 
os jogos Falcons e Eliminator, e o simulador de 
vôo subLOGIC Flight Simulator, cujo título ficou 
apenas como “Simulador de Vôo". 





Ao lado, algumas telas do jogo 
“Karateka" do TK-2000. 

























































































































Livro “CoCo: The Colorful History of Tandy’s 

Underdog Computer” 



Juan Castro 


F az sentido amar um objeto inanimado? Talvez sim, 
se esse objeto carrega em si histórias envolventes de 
pessoas interessantes com as quais um leitor pode 
se identificar e se emocionar. E esse é certamente o caso 
da história do TRS-80 Color Computer, mais conhecido nas 
rodas da "malandragem" como TRS-Color, ou CoCo para 
os íntimos. 

Este livro nasceu na mente de Boisy Pitre, americano 
da Louisiana que participou do desenvolvimento do sis¬ 
tema operacional OS-9 e é figura-chave da comunidade 
CoCo até hoje (comunidade essa muito ativa e saudável, 
por sinal). Um diferencial deste livro em relação a outros 
recentes livros sobre micros clássicos está no outro autor, 
Bill Loguidice, conhecido escritor e colunista da área de 
videogames e também fã e usuário de longa data de TRS- 
Color. A qualidade do texto é muito superior à média de 
outros livros sobre o assunto. 

O primeiro capítulo faz um apanhado rápido da 
história da computação focando nas raízes da empresa 
Tandy Radio Shack (resultado da fusão de duas empre¬ 
sas que, ora vejam vocês, se chamavam Tandy e Radio 
Shack) e da sua entrada no mercado de informática. De¬ 
talhe: a Tandy, pré-Radio Shack, era uma fabricante de 
artigos de couro! Daí pra frente, basicamente seguimos a 
história do projeto Color Computer dentro da Tandy, com 
desvios estratégicos para falar sobre os participantes do 
"ecossistema". Destes, dois merecem destaque especial: A 
revista Rainbow, uma das publicações sobre informática 
mais longevas da história (começou a ser publicada em 
1981 e sobreviveu dois anos depois de seu próprio assunto 
ter saído do mercado), capitaneada pelo altamente fol¬ 
clórico Lonnie Falk, e a software-house MicroWare, criado¬ 
ra do supracitado sistema operacional OS-9, que turbinou 
o uso profissional do CoCo (algo que a Tandy não previa, 
mas que foi obviamente muito bem-vindo). 

Conhecedores da plataforma, mais frequentemen¬ 
te na forma do clone nacional CP400, certamente se de¬ 
liciarão com as revelações de como certos detalhes téc¬ 
nicos exóticos vieram a acontecer, começando com um 
projeto de teleinformações para fazendeiros que, por um 
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caminho enviesado, veio 
a dar origem ao CoCo. 
Em destaque também a 
preservação das famosas 
"cores falsas" no CoCo 2 e 
a criação do chip GIME do 
CoCo 3. 


E por falar em clo¬ 
nes brazucas... Sim, eles 
são citados! Todos eles! 

Em nome da transparência, 

devo citar que este que vos fala, em parceria com Da¬ 
niel Campos, colaborador da Jogos 80, contribuiu para 
esse trecho em particular, com direito a citação, créditos 
e tudo. É só um parágrafo, mas foi o suficiente para inflar 
nossos egos consideravelmente. 

Porém tudo que é bom acaba... Assim como filmes 
e livros sobre cachorros, você sabe que o capítulo sobre 
"O Fim" eventualmente tem que chegar. Mas assim como 
os Marleys da vida deixam filhotes, o CoCo deixou uma 
comunidade que segue firme e forte até os dias de hoje, 
criando hardware e software novos e sem dar o menor 
sinal de parar. Tudo isso é registrado, e para fechar o livro 
com chave de ouro, o autor visita em pessoa o engenhei¬ 
ro da Tandy que insultou (com direito a palavrão) um 
chip da Motorola dentro da fábrica da Motorola. 

Resumindo: se você tem pelo menos um pouqui¬ 
nho de interesse sobre história da informática, compre 
este livro. Mesmo que você seja daqueles que só quer 
saber de Commodore 64 ou MSX ou Apple II, você vai 
gostar. 


Onde Comprar o livro: 

Versão tradicional: 

http : //www. amazon. con/CoCo-Colorful-History-Underdog-Coniputer/ 
dp/146659Z478/ref=tmijapJitleJ?ie=UTF8Íqid=1401044670Ísr=B-l 

Versão poro Kindle: 

http : //uuu.aiuazon.con/CoCo-Colorful-History-Underdog-Conputer- 
ebook/dp/B00HRGWNXC/ref=triirii kin suatch 0? encoding=UTF8íiSr=8-l- 
& : qid=1401044670 

























































Flávio Masao Matsumoto 





Crédito da foto: Wikipédia. 


E ste artigo dá continuidade à série de hacking de programas no TK90X. Certamente, o meio mais 
disseminado de armazenamento e distribuição de programas e dados para esta linha de computador 
foram as fitas cassetes. Na época, essa era uma das formas mais acessíveis de se gravar e reproduzir sons 
e músicas, que acabou sendo inteligentemente aproveitado para codificar sequência de bits. 

Durante a gravação, o sinal elétrico oscilante que representa sons é equalizado, amplificado e enviado 
ao cabeçote, cuja bobina cria um campo que faz a magnetização permanente do material ferromagnético 
contido na fita. A reprodução funciona no sentido contrário, isto é, o padrão magnético gravado na fita gera 
uma diminuta corrente elétrica na bobina do cabeçote, a qual é equalizada e amplificada em nível suficiente 
para acionar um alto-falante. Os gravadores geralmente possuem uma saída para o sinal amplificado para 
fones de ouvido, rotulada de "EAR", e uma entrada "MIC" para microfone. Interligando-se os conectores EAR e 
MIC do computador e do gravador entre si, era possível transferir dados de/ou para a fita cassete. As interfaces 
EAR e MIC do TK90X são bastante simples, reconhecendo somente dois níveis de sinais correspondentes ao 
dígito binário 0 (baixo) e 1 (alto). 

Não há um circuito eletrônico dedicado (demultiplexador) para decodificar os sinais oriundos do gravador, 
operação que é feita por software. O sinal de EAR é lido na porta de entrada 254 em seu bit 6, a mesma que 
faz a leitura do teclado, e a interface MIC é acionada pela porta de saída de mesmo endereço que controla 
também o som e a cor da borda da tela. Alternando-se periodicamente o bit 3 da porta 254 como saída, um 
sinal no formato de onda quadrada é enviado ao gravador. A gravação ou leitura é realizada através das 
instruções IN ou OUT do Assembly Z80 na referida porta (embora tais instruções existam no BASIC, a lentidão 
desta linguagem inviabiliza seu uso). 


CODIFICAÇÃO DE DADOS PADRÃO DA ROM DO TK90X 

Como a entrada e saída de dados entre o gravador e o TK90X são feitas por um único canal, isto é, tem 
natureza serial, os bits devem ser transferidos sequencialmente. Poder-se-ia pensar que bastaria tomar de forma 
direta o estado do bit 6 da porta 254, porém, isto não funcionaria, pois seria necessária uma sincronização 
perfeita entre o computador e o gravador. Tal sincronia é impossível porque o mecanismo de tração não é 
muito preciso, o que causa variação da velocidade da fita sobre o cabeçote. No lugar da amplitude de sinal 
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de EAR, as rotinas da ROM codificam os dados através de diferentes intervalos de tempo entre transições de 
níveis lógicos 0—>1 e 1—>0, como será explicado mais adiante. 

O tempo no computador é medido como múltiplo do período (7) do clock do microprocessador, que é 
correspondente ao recíproco de sua frequência (7=1/0. No caso do TK90X, com frequência de clock do Z80 
de 3,575611 MHz, o período 7 corresponde a 279,672 ns (nanossegundos, ou bilionésimos de segundo). Este 
valor é ligeiramente inferior a 285,714 ns do ZX Spectrum, pois o clock no computador britânico é de 3,5 MHz. 
Tal diferença não interfere seriamente no carregamento da fita, pois a rotina de carregamento é bastante 
tolerante à variação de frequência. Cada instrução do Z80 gasta um tempo de execução que é medido em 
múltiplos de 7 e, com uma contagem minuciosa desses tempos em um trecho de código de máquina, pode-se 
calcular o intervalo que se leva para ser executado. As rotinas de gravação e leitura da ROM são projetadas 
sob parâmetros precisos de temporização, sendo a sua modificação algo nada trivial. 

Um bloco de dados salvos em fita é precedido por um tom inicial contínuo, mais grave, reconhecível por 
criar um padrão alternado de cores vermelho/ciano na borda da tela. O intervalo de tempo entre as transições 
de níveis lógicos é de 2168 7, o equivalente a 606,3 //s (microssegundos, ou milionésimos de segundo) ou uma 
frequência de 825 Hz. Este sinal, conhecido como piloto, serve como guia para que a rotina de carregamento 
espere por impulsos de sincronização com rampa em nível baixo (0) de 667 7 (186,5 //s), seguido de rampa em 
nível alto (1) de 735 7 (206,6 / us ). Neste momento, as transições do sinal do gravador são representadas pela 
alternância de cores entre azul e amarela. Após o impulso de sincronização, são enviados os dados, um bit 
de cada vez. O bit com valor 0 é representado por um intervalo de 855 7 (239,1 //s) em rampa em nível lógico 
baixo, seguido de igual tempo de rampa em nível alto. O bit com valor 1 é formado por um par de rampas de 
1710 7 (478,2 /ís), que é o dobro do período do bit de valor 0. Esta diferença apreciável de codificação temporal 
entre os valores 0 e 1 evita que as variações do gravador afetem a interpretação do sinal. O diagrama de 
tempos abaixo, dado como exemplo, mostra o final do tom piloto, o pulso de sincronização e o início de uma 
sequência de bits de valores 0, 0 e 1. 
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2r68 667 735 855 855 855 855 mo 

T TTTTTT T 


sincroni¬ 

zação 


dados em bits 



> 


JOGE 



16 













































































As rotinas da ROM se encarregam de organizar os dados em octetos de bits formando os bytes, que 
são como estão armazenados na memória. Além dos dados em si, dois bytes adicionais são gravados na 
fita, os quais não serão armazenados na memória durante a leitura. O primeiro byte, conhecido como líder 
0 leader ), indica o tipo do bloco salvo e, no BASIC, pode assumir somente os valores 0 ou 255. O último byte, 
a paridade, serve como dígito verificador da integridade do dado que acaba de ser lido, servindo como 
método rudimentar para detectar erros de leitura. 

Quando se salva um programa ou dado para a fita através do comando s r u e do BASIC, são enviados 
dois blocos de bytes para a fita. O primeiro bloco, conhecido como cabeçalho ( header ), é identificado com 
o byte líder de valor 0 e contém dados como o nome do arquivo salvo, tipo de dado salvo (programa BASIC, 
matriz ou conteúdo da memória), comprimento e outras informações relevantes. Seu comprimento é de 17 
bytes e a sua estrutura é representada na tabela abaixo. Em seguida, após uma pausa, é enviado o bloco que 
contém os dados propriamente ditos, precedido pelo byte líder de valor 255. Por exemplo, quando se salva 
uma tela de 6912 bytes com o comando s R u E "nome"SCREEN$, grava-se um cabeçalho de 152 bits (19 
bytes, sendo o primeiro byte, o líder, igual a 0) seguido por um bloco de 55312 bits (6914 bytes, com byte líder 
igual a 255). 


Tipo 

Byte 

0 

1 - 10 

11-12 

13-14 

15 

16 

BASIC 

0 

nome do 
arquivo 
(10 

caracteres) 

comprimento 
do bloco 

número de 
linha 

de execução 

comprimento do programa sem 
as variáveis do BASIC 

matriz 

numérica 

1 

— 

nome da 
matriz 

— 

matriz de 
string 

2 

— 

nome da 
matriz 

— 

CODE ou 
SCREEN$ 

3 

— 

endereço de carregamento 


São duas as principais rotinas da ROM envolvidas diretamente com transferência de dados entre o 
TK90X e o gravador. A rotina que se inicia em 1218 (#04C2 hexadecimal), rotulada como SA-BYTES, salva 
um bloco da memória para a fita. Antes desta rotina ser acionada, deve-se colocar os seguintes valores em 
registradores do Z80: o byte líder em A, o endereço do início do bloco em IX e o comprimento do bloco em 
DE. Outra rotina é LD-BYTES, que se inicia em 1366 (#0556 hexadecimal) e serve para carregar ou verificar 
um bloco salvo na fita. A rotina emprega em sua entrada os seguintes registradores: A com o byte líder, IX 
com endereço a partir do qual o bloco será armazenado na memória e DE com o comprimento. O flag carry 
especifica se vai ser realizado um carregamento dos dados (carry igual a 1) ou apenas uma verificação sem 
alterar a memória (carry igual a 0). Para entender com profundidade o funcionamento da gravação e leitura 
de dados em fita, recomenda-se a leitura do capítulo 4 do livro "O Sistema Operativo do Spectrum: ROM 
Disassembly" de I. Logan e F. O' Hara. Os trechos de programas em Assembly a seguir ilustram usos típicos das 
rotinas mencionadas: 


; O trecho a s e gui 
LD fi,255 
LD IX,0 
LD DE , 16384- 

CRLL SR-BYTES 


r 

s a L v a 

a ROM 


De fine 

by te 

* 

flp o n ta 

para 


Com pri 

mento 

j 

Sa Lva 

bloco 


do TK90X em fita 
Leader como 255. 
inicio da ROM. 
da ROM. 




— 
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; O trecho a s e gu 

LD fi,255 

LD IX , 16384- 

LD DE,6912 

5CF 


r carrega uma teta da fita. 

; Define by te Leader como 255. 

; flponta para inicio da área da teta na RAM. 

Comprimento dos dados da teta. 

; Levanta carry para fazer LOflD ao invés de UERIFY. 


CflLL LD-BYTES 


Ca r r e ga o bloco. 


PROGRAMAS DESPROTEGIDOS 

A rigor, a linguagem nativa do TK90X permite gravar somente programas em BASIC através do comando 
srue "nome". Entretanto, devido às limitações desta linguagem, a grande maioria dos programas 
comerciais são elaborados em Assembly e convertidos em código de máquina, que é uma sequência de 
bytes armazenada na memória com instmções executadas pelo Z80. A instmção srue "nome"CODE 
endere ç o_ini cia t , comprimen to salva uma sequência arbitrária de bytes da memória e, por isso, 
é empregada para salvar códigos de máquina. Podem-se salvar outros tipos de dados; por exemplo, srue 
"nome"CODE 16334-,6912 salva o conteúdo da tela, embora seja preferível o uso da forma mais curta 
srue "nome "screení. Para o carregamento, usam-se as formas correspondentes da instrução l o r d . 

A maior parte das fitas de jogos comerciais se inicia com um programa BASIC bastante curto, cuja 
função principal é carregar um ou mais blocos de bytes com programas em código de máquina e dados. 
Dentre esses blocos, é comum a presença de uma tela logo após o carregador em BASIC, a qual é exibida 
durante a carga dos blocos restantes (tela de carregamento ou loading screen). Um exemplo de programa 
com esta estrutura é o jogo A/lofos de 1987, publicado pela Mastertronic Added Dimension. A sua listagem 
BASIC é: 


10 CLERR 24-575 
20 LORD ""SCREENÍ 

30 INK 0: PRPER 0: PRINT RT 0,0; 
4-0 LORD ""CODE 

50 RRNDOMIZE USR 32763 


A instrução CLEAR define o topo da RAM (RAMTOP) usada pelo sistema BASIC, isto é, o endereço a partir 
de 24576 fica disponível para o código de máquina. Na linha 10 ocorre o carregamento da tela e, para evitar 
que esta seja corrompida pela mensagem "Bytes: nome" que é impressa pela instrução l o r d , na linha 
30 são escolhidas cores e posição do cursor para que a impressão fique oculta. A linha 40 faz o carregamento 
do código de máquina que é posteriormente executado por usr 32763, cujo argumento numérico é o 
endereço de início da execução. 

Como o programa não possui nenhuma proteção, basta pressionar BREAK antes que o carregamento 
se complete para ter acesso ao programa carregador. Após o controle do computador retornar ao editor 
BASIC, pode-se ajustar as cores da tela e ver a listagem do carregador. Para analisar o código de máquina, 
executa-se clerr 24575 e se avança a fita até o início do respectivo bloco, que deve em seguida ser 
carregado com lord ""CQDE.a partir deste ponto, o código de máquina pode ser listado por um utilitário 
disassemb/er. 

Embora estes passos sejam suficientes para fazer o Disassembly, faltam informações para poder transferir 
o programa para outras mídias, como, por exemplo, disquetes. Neste caso, é necessário um utilitário que 
faça a leitura e análise do cabeçalho de cada bloco salvo na fita. O programa STK (disponível em http 1 7/ 
UUU. uorldofspectrum.org/infoseekid. C9i?id=0013806> é um desses utilitários, cujo comando J (LOAD) seguido de 
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GRAPHICS (teclas caps-shift e 9) analisa um cabeçalho 
presente à fita e lista seu conteúdo, tal como mostra a 
figura ao lado: 


PROGRAMAS PROTEGIDOS 

Os produtores de software passaram a empregar 
esquemas de proteção na tentativa de evitar as cópias 
piratas. Um dos pontos mais vulneráveis é o carregador 
BASIC que, embora seja gravado para ser executado 
automaticamente logo após sua carga, pode ser 
interrompido com a tecla BREAK. A intermpção de um 
programa BASIC faz com que a execução do Z80 passe 
para a rotina de tratamento de erro, cujo endereço fica 
no elemento da pilha de máquina apontado pela variável de sistema ERR_SP, localizada em 23613/24614. 
Para fazer com que o endereço de retorno seja 0 (isto é, a inicialização do computador), basta colocar a linha 
abaixo logo no início do carregador: 

15 LET e=PEEK 23513 +256 íPEEK 24-614: POKE e,0: POKE ê+1,0 

Qualquer interrupção do BASIC resultará no reset imediato do TK90X. Esta proteção pode ser contornada 
se o BASIC não for executado logo após a carga, isto é, se o argumento line do comando sfiue for ignorado. 
A instrução merge, que junta um programa BASIC da fita ao que está na memória, serve para este propósito. 
Executando oMERGE 1 ' 1 ' com a memória limpa, o programa é carregado sem ser executado. Mesmo assim, 
o truque com MERGE não é infalível, pois um bug da ROM faz com que uma linha BASIC mal estruturada trave 
o computador. Se forem adicionadas as seguintes linhas no final de um programa, 

9996 POKE PEEK 23637+256íPEEK 23636+3,1: 5RUE "NoMerge" LINE 10 
9999 REH 

a instrução POKE aumenta o campo do comprimento da linha 9999 em mais 256 bytes e, assim, torna-o 
inadequado para fazer MERGE. 

Para poder analisar os programas assim protegidos, deve-se usar um utilitário para desativar a auto- 
execução de qualquer programa BASIC, tal como o STK, que possui para tal finalidade o comando Z (BLOAD). 
Outro utilitário que pode ser usado é o *LOAD do Jon North, cuja listagem foi publicada na revista Your Sinclair 
(disponível em http ; //luju.uor1dofspectrun.org^shouurap.cgi?pa9e=hth56.html#load ou ftp ; //ftp.uorldofspectrun.org^ 
pub/'sinclair/ma9azines/YourSinclair/Issue56/Pa9es/YourSinclair5600045. jpg). 

PROTEÇÃO CONTRA LISTAGEM 

Uma vez carregado o programa BASIC sem que esteja sendo executado, há um outro obstáculo a ser 
enfrentado, que é a proteção contra listagem. Após rodar o programa abaixo, 

10 REH X X X X X X X 

20 LET b=PEEK 23635+256*PEEK 23636+5 
30 FOR e=b TO b+6: RERD a: POKE e,a: NEXT e 

40 DRTR 22,0,0,16,7,17,7 

nada legível aparece na listagem. Isto ocorre porque as letras x da linha REM foram substituídas por códigos 
de controle de impressão que correspondem aos comandos RT 0 , 0 j ink 7 j prper 7 , Códigos de 
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controle deste tipo podem ser espalhados por todas as linhas, o que tornaria tedioso removê-los manualmente. 
Em casos assim, é interessante usar novamente o utilitário STK, cujo comando L (LIST) exibe a listagem BASIC 
ignorando os códigos de controle. 

Mesmo assim, há mais uma forma de proteçáo para despistar uma tentativa de listar o programa. O 
programa da linha abaixo, 

10 PRINT 1 

quando executado, retornará o dígito 1 na tela, como seria esperado. Digitando-se na linha de ediçáo o 
comando abaixo, 

POKE PEEK 23635+256*PEEK 23636+10,1 

ele náo alterará a listagem BASIC. Porém ao rodar o programa, será impresso na tela o valor 257. Qual seria a 
razão dessa discrepância? Uma constante numérica é armazenada de duas formas numa linha de programa, 
sendo constituída por uma sequência de caracteres ASCII compreensível ao ser humano, seguido de um byte 
marcador de valor 14 (#0E) e do número em codificação binária de 5 bytes. Os caracteres ASCII são exibidos 
durante a listagem, porém ignorados durante a execução. Neste último modo são empregados números 
codificados em 5 bytes, que é o formato diretamente empregado pela máquina. Esta dupla codificação é um 
engenhoso truque para aumentar a velocidade de edição, listagem e execução de uma linha. No exemplo 
dado, a linha 10 estaria assim armazenada na memória: 


Posição 

0 

i 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

Valor 

0 

10 

9 

0 

245 

49 

14 

0 

0 

1 

0 

0 

13 

Significado 

n° da 
linha 

comprimento 
da linha 

PRINT 

1 

marcador 

constante 1 

enter 


No exemplo acima, a constante 1 é codificada nos 5 bytes como 0, 0, 1, 0, 0. O POKE alterou o código 
para 0, 0, 1, 1, 0, que corresponde ao valor 257. 

Resumindo, é possível camuflar completamente as constantes numéricas de forma que a listagem não 
corresponda ao que efetivamente será executado. Infelizmente, o STK não provê meios para superar esta 
proteção, porém o utilitário *LIST, de Jon North, é capaz de identificar as constantes corretamente. A listagem 
deste utilitário foi publicada na revista Your Sinclair e está disponível em httpá/wuw.worldofspectrillil.or?/ 
shoijurap.C 9 i?page=hth 56 .htmliload ou ftp ; //ftp.uorldofspectruM. org^pub/sinclair/magazines/YourSinclair/IssueSè/ 

Pa 9 es/YourSinclair 5600045 .jpg. 

Mesmo depois de obter acesso à listagem, um programa pode ser deliberadamente feito para ser de 
difícil compreensão, com uso de expedientes pouco ortodoxos como, por exemplo, fazer POKE para realizar 
desvios. Casos assim requerem um conhecimento mais profundo do funcionamento do BASIC do TK90X. 

PROGRAMAS COM BLOCOS SEM CABEÇALHO (“headerless”) 

Os programas que usam instrução LOAD do BASIC para carregar suas partes da fita são fáceis de ser 
copiados, por isso foram desenvolvidos vários esquemas de proteção. Por não serem reconhecidos pelo BASIC, 
as rotinas de carregamento são elaboradas em Assembly. Como já foi explicado, os dados salvos pelo BASIC 
são compostos de dois blocos, sendo o primeiro um cabeçalho. Não é difícil criar rotinas que carregam (e 
salvam) blocos de memória em Assembly, sem a necessidade de um cabeçalho. Blocos salvos dessa forma 
são conhecidos como headerless (sem cabeçalho). 

A versão 128 K de Cybernoid II: The Revenge, jogo publicado pela Hewson em 1988, possui dois blocos 
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headerless. Seu carregador BASIC é: 


10 CLERR 24999 

20 PAPER 0: BORDER 0: INK 6 
30 CL5 LET a =PEEK Í14446) 

40 IF a=255 THEN GÜ SUE 120 
50 PRINT : PRINT : PRINT 

60 PRINT " NOTE THE 5ELECTION KEY CHANGE5" 
70 PRINT : PRINT 

S0 PRINT " Y = 5MRRT BÜMB" 

90 PRINT " U = TRACERS" 

100 LÜRD "cyberCODE 
110 RRNDÜMIZE USR 25000 
120 PRINT : PRINT : PRINT 

130 PRINT " THIS IS THE 12SK UERSION" 

140 PRINT 

150 PRINT " PLERSE USE ÜTHER SIDE ÜF TRPE" 
160 RETURN 


A linha 100 carrega uma pequena rotina em código de máquina que é executada na linha 110a partir do 
endereço 25000. O Disossembly produz: 


25000 

Dl 



25001 

LD 

IX 

,32766 

25005 

LD 

DE 

, 6912 

2500S 

CRLL 

25036 

25011 

LD 

HL 

,32766 

25014 

LD 

DE 

,16364 

25017 

LD 

EC 

, 6912 

25020 

LD IR 


25022 

LD 

IX 

,25344 

25025 

LD 

DE 

j 40191 

25029 

LD 

HL 

,25344 

25032 

PUSH 

HL 

25033 

UR 

25036 


; Desabi Li ta interrupção. 

j Endereço inicial de carga em 3276S. 
j Comprimento do bloco de 6912 bytes, 
j Carrega o bloco, 

j Copia os bytes carregados em 32763 para 
; área de video em 1S3S4 , 


a 


j Endereço inicial de carga em 25344, 
j Comprimento do bloco de 4C191 bytes, 
j Endereço para iniciar o jogo que é guardado 
;na pilha do ZSC, 
j Carrega o bloco. 


; O tre 

C h O 

a baix o 

25036 

LD 

R , 255 

25036 

6 CF 


25039 

INC 

D 

25040 

EX 

RF j RF' 

25041 

DEC 

D 

25042 

LD 

R , 15 

25044 

OUT 

(254) 


é sub-rotina que faz carregamento de um 
j Ualor do byte líder é 255, 
j Levanta flag CRRRY, para fazer 
j Rotina semelhante ao LD-BYTES, 


bloco , 

LORD . 


R 


Torna branca a borda. 


25046 UR 137S 


Continua na ROM o carregamento da fita. 


Pode-se ver que a sub-rotina em 25036 é chamada duas vezes, sendo que antes o registrador IX é 
carregado com valor do endereço inicial e DE com comprimento do bloco. Analisando esta sub-rotina, percebe- 
se que salta para a ROM em 1378 (#562), que é um pouco adiante da LD-BYTES; neste caso, uma parte da 
rotina da ROM foi suprimida para evitar que um erro de leitura resulte em retorno ao monitor BASIC. 

Existe ainda um número considerável de jogos que fazem uso de rotinas próprias de carregamento, 
que não da ROM. Várias destas rotinas são baseadas na LD-BYTES com pequenas modificações como cores 
diferentes de borda da tela, temporizações diferentes para obter maior velocidade ou alguns efeitos gráficos 
como contador regressivo. Nestes casos, os registradores IX, DE e A têm a mesma finalidade que na rotina da 
ROM, tornando a interpretação do Disassembly um pouco mais fácil. 


Este artigo continuará no próximo Jogos 80, edição de Dezembro. 
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SCRAMBLE ±±±± 

Atari Age (Robert DeCrescenzo) para 
Atari 7800 
Gráücos/Som: 9 
Ação/Controles: 8 


Marcus Vinícius Garrett Chiado 


S cramble, arcade lançado pela 
Konami em 1981 e distribuído 
pela Stern nos E.U.A., foi um divisor 
de águas no mundo dos games, 
o primeiro do gênero Horizontal 
Scrolling Shooter a conter cenários 
diferenciados. No comando de um 
jato, que mais se parece com um 
foguete, o jogador deve destruir 
naves e veículos inimigos ao passo 
que precisa evitar a colisáo contra 
eles e contra o terreno, o qual varia 
conforme a tela em que a açáo se 
desenrola em dado momento. É ne¬ 
cessário abastecer o jato durante o 
voo, o que pode ser feito sempre que 
se destroem tanques de combustí¬ 
vel na superfície do planeta ou den¬ 
tro de cavernas. Como armamento, 
o jogador possui laser e bombas. 
Trata-se de uma fórmula copiada à 
exaustáo por inúmeros outros títulos 
e igualmente pela própria Konami, 
que lançou quase na sequência o 
mais reconhecido Super Cobra. 

A versáo em análise é a do 
Atari 7800, lançada em 2012 pelo 
selo Atari Age e programada por 
Robert "PacManPlus" DeCrescenzo. 


Assim como no fliperama, cada 
rodada consiste de cinco estágios 
mais um, a base, que deve ser ven¬ 
cida ao final. Os inimigos que o jo¬ 
gador enfrenta sáo foguetes, UFOs, 
tanques de combustível (para re¬ 
abastecimento), naves e a base 
propriamente dita. No entanto, um 
tipo de ameaça que náo pode ser 
destruída sáo os meteoros, os quais 
devem ser evitados por meio de 
manobras evasivas. O botáo es¬ 
querdo do joystick dispara o laser, o 
botáo direito lança as bombas - os 
armamentos, ao contrário do com¬ 
bustível, sáo ilimitados. As pontua¬ 
ções proporcionadas pela destrui- 
çáo dos adversários variam de 50 a 
300 pontos de acordo com o que for 
alvejado. 

As telas trazem desafios espe¬ 
ciais na forma de inimigos/cenários/ 
terrenos distintos, cada qual com 
suas particularidades. As telas sáo: 
Launching Rockets (estágio um), 
UFOs and Caves (estágio dois), Me- 
teors (estágio três), Launching Ro¬ 
ckets from Tall Structures (Estágio 
quatro), Winding Maze of Buildings 
(estágio cinco) e Base (estágio seis, 
final). Ao se destruir a base, o jogo 
recomeça mais difícil, isto é, na ro¬ 
dada seguinte os inimigos sáo mais 
rápidos e agressivos, e a nave do jo¬ 
gador consome mais combustível. 

Há três níveis de dificuldade 
que podem ser escolhidos no menu 
inicial. No Easy (fácil), os foguetes 
náo sáo disparados e o consumo 
de combustível do jato do jogador é 
bem lento. No Normal, apenas dois 
foguetes sáo lançados simultanea¬ 
mente na mesma tela e o consumo 
de combustível é normal - é a difi¬ 
culdade que se encontra no arcade 
original da Konami. No Hard (difícil), 
os foguetes sáo disparados à von¬ 
tade e o consumo de combustível 
é alto - é a mesma dificuldade do 
arcade na versáo padráo da Stern. 


Ganha-se uma vida extra a cada 
10 mil pontos e é possível jogar em 
dois jogadores, mas de forma náo 
simultânea. 

Em termos visuais, o jogo do 
Atari 7800 apresenta gráficos im¬ 
pressionantes, coloridos e bem de¬ 
talhados, lembrando muito o arca¬ 
de. O jato do jogador, por exemplo, 
possui a mesma animação do flipe¬ 
rama, com direito ao rastro da turbi¬ 
na e às luzes de navegação piscan- 
tes. Duas diferenças, entretanto, são 
notórias: a ausência das estrelas no 
gráfico de fundo e o scroll, não tão 
"liso" quanto o original; claro, devi¬ 
do às limitações técnicas do video- 
game. Os efeitos sonoros são muito 
bons e lembram os do fliperama. 
O gameplay está bem próximo à 
versáo do arcade, principalmen¬ 
te porque o programador parece 
ter estudado a ROM original para 
que se mantivessem os detalhes e o 
comportamento da máquina. 



A apresentação do produto 
é boa, o labei é bonito e bem im¬ 
presso, o manual de instruções é 
detalhado, bonito e bem impresso 
também. Um produto de ótima qua¬ 
lidade, comercializado pela Atari 
Age, que proporciona uma experi¬ 
ência de jogo ótima aos fanáticos 
por Scramble. Certamente, uma das 
melhores conversões para os conso- 

> 













































JOYSTICK 


les e micros de 8 bits. 

Dicas: Quando enfrentar os mete¬ 
oros, procure ficar próximo ao solo 
sempre que possível, somente su¬ 
bindo por breves momentos para 
que não colida contra o terreno. Ao 
enfrentar os UFOs, procure perma¬ 
necer na metade da tela e dispare 
rapidamente e com regularidade; 
será mais fácil alvejar os inimigos. 



THE ELIMINATOR ±±±± 

Adventure International para 
Apple II e compatíveis 
Gráficos/Som: 8 
Ação/Controles: 8 


THE ELIMINATOR ±±±± 

Plan-Soít , SoítKristian, Microsoft e 
Cibertron para TK2000 
Gráficos/Som: 8 
Ação/Controles: 8 


Georg Bahr Julião 


E m The Eliminator, você é o piloto 
de uma nave de defesa espacial 
e tem como objetivo destruir as na¬ 
ves alienígenas inimigas. Com uma 
tela de início bem bacana e colori¬ 
da, o jogo cativa pelos gráficos em 
alta resolução e pelos efeitos sono¬ 
ros, diferenciados para indicar tiros, 
explosões e o som do motor (a nave 
desligada não emite som). O jogo 


permite encher a tela com uma ra¬ 
jada de diversos disparos simultâ¬ 
neos, fato incomum nos primeiros 
títulos de nave. A cada nível, apre- 
senta-se um novo predador inimigo, 
o que amplia a diversidade da frota 
alienígena. Cada uma das naves 
possui um padrão de voo próprio e 
uma forma de atirar diferenciada, 
portanto, cuidado! Detalhe crucial: 
todas seguem em rota suicida de 
colisão contra o jogador. 

Deve-se progredir por 15 ní¬ 
veis. Ao se atingir o 15°., o jogo se 
mantém nele até o fim das vidas. 
A pontuação conseguida pela des¬ 
truição de cada nave é progressiva 
de acordo com o nível. Com tantos 
predadores, é óbvio que alguns me¬ 
recem apelidos, como por exemplo, 
o "elefantinho" (nível 9) e a "águia" 
(nível 10). Há duas formas de se 
progredir para a próxima fase: des- 
truindo-se todos os inimigos e atin¬ 
gindo-se a máxima progressão na 
barra de status. Ao passar de fase, 
uma sequência de telas coloridas 
pisca (efeito ausente na versão do 
TK2000) e um beep característico 
soa antes de se iniciar um novo ní¬ 
vel. 



Duas são as formas de mor¬ 
rer: colisão direta com um inimigo e 
destruição do escudo defletor. Para 
evitar essas fatalidades, deve-se 
desviar das naves inimigas e, claro, 
dos disparos. Após a morte do jo¬ 
gador, todas as naves da tela "tiram 


uma casquinha" dele, ou seja, vão 
ao seu encontro em um efeito que 
aumenta a sensação de destruição. 
Aliás, o jogo poderia ter um radar 
com a posição dos inimigos, porém, 
o "scroll" da tela é tão curto que 
eles passam e logo reaparecem no¬ 
vamente - além do fato de que se 
pode inverter o sentido da nave. 


-jçftr 


-_ 


25 pontos 

50 pontos 

75 pontos 

100 pontos 

125 pontos 

150 pontos 

175 pontos 

200 pontos 

225 pontos 

250 pontos 

300 pontos 

350 pontos 

400 pontos 

450 pontos 

500 pontos 

1000 pontos 


Como padrão ao iniciar, po¬ 
demos escolher os níveis de 1 ao 4. 
Ao reiniciarmos, podemos optar por 
começar uma partida por qualquer 
nível até o alcançado na jogada 
anterior. Para começar em um nível 
mais avançado, espere até que a 
demonstração seja iniciada e mos¬ 
tre um nível superior ao 4, então, ini¬ 
cie o jogo. Lembramos que o nível 
máximo possível para iniciar é o 10, 
ou seja, se o jogador morrer entre os 
níveis 10 e 15, só poderá reiniciar 
no 10°. Isso é recompensado com 
70000 pontos ao se passar para o 
nível seguinte (11). Após muita in¬ 
sistência em tentar "virar" o placar 
(mais de 100000 pontos), vem a re¬ 
compensa: as naves, tanto a do jo¬ 
gador como as inimigas, ficam com 
as cores invertidas. Lembrando que 
no Apple é possível jogar tanto com 
joystick/paddle quanto com tecla¬ 
do. No TK2000 somente é possível 
jogar com teclado. 

Curiosidades: Lançado em 1981, 
The Eliminator foi o primeiro título 
de John Anderson para Apple II. A 
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versão para o Apple II, assim como 
a do TRS-80, começou como um 
clone de Defender (da Williams), 
porém, a produtora queria mudan¬ 
ças para limitar as semelhanças. 
John Anderson decidiu mudar sua 
versão para acontecer em espaço 
aberto, podemos até visualizar al¬ 
gumas luas crescentes "sorridentes" 
pela tela. Sendo assim, o jogo se tor¬ 
nou "muito" diferente de Defender - 
o que evitou uma ameaça de ação 
judicial. Mais tarde, John afirmou 
que lamentava a decisão e achava 
que deveria ter mantido Eliminator 
mais parecido com Defender. Curio¬ 
samente, a versão do TRS-80 se tor¬ 
nou a oficial de Defender, o que não 
aconteceu com a do Apple II. 

Para o TK2000, o jogo foi lan¬ 
çado por pelo menos quatro sof- 
thouses nacionais, todas derivadas 
da versão para Apple II. O progra¬ 
mador Luis Nakanishi (vide entrevis¬ 
ta nesta edição) efetuou ao menos 
uma das conversões para o TK2000 
quando trabalhava na Plan-Soft. 



OPEN, SESAME! ± 

BitCorp. para Atari 2600 e compatíveis 
Gráfícos/Som: 3 
Ação/Controles: 4 


Eduardo Antônio Raga Luccas 


C ontinuando com a nossa série 
de análises dos jogos da CCE 
para o Atari, desta vez vamos ver 
o jogo "Open, Sesame!" ou, na fe¬ 


liz tradução do cartucho, "Abre-te, 
Sésamo!". Este jogo tem algumas 
curiosidades, especialmente aqui 
no Brasil, vamos comentar ao final, 
mas a primeira é ao ligar o: ele tem 
- acreditem - uma voz sintetizada 
que diz o nome do jogo, "Open Sesa- 
me". Claro que se devem levar em 
conta as limitações do valente Atari 
2600, obviamente a voz não é um 
primor em qualidade, mas até que 
ficou bem razoável. Ainda mais se 
considerarmos que este é um título 
de apenas 4 KBytes! Imaginemos, 
portanto, que a famosa frase "abre" 
o jogo para que possamos jogá-lo! 

Quanto ao jogo em si, infe¬ 
lizmente, não é dos mais interes¬ 
santes. Você personifica o famoso 
xeique árabe Ali Babá e deve subir 
todos os níveis das plataformas até 
o último - onde está o tesouro de Ali 
Babá. Para conseguir, deve lançar 
todas as cordas de todos os andares 
das plataformas (são duas em cada 
andar), e para isto, basta ficar em 
cima do pontinho piscante e aper¬ 
tar o botão. TODAS devem ser lan¬ 
çadas, caso contrário não será pos¬ 
sível a Ali Babá pegar o tesouro. 

Como elemento de dificulda¬ 
de, há os guardas circulando em 
todos os níveis das plataformas, um 
guarda em cada nível. Se tocar em 
Ali Babá, você perde uma vida. Os 
guardas só podem ser anulados se 
você pegar a "bola mágica", que 
te concederá poderes temporários. 
Enquanto estiver com estes poderes, 
basta tocar no guarda que ele cai¬ 
rá. O poder dura pouco tempo ou 
até que se derrote o guarda, quan¬ 
do você voltará ao normal. 

Após içar as cordas de cada 
andar, suba, por qualquer uma de¬ 
las, e faça o mesmo processo em 
cada andar. Caso o guarda do an¬ 
dar venha incomodá-lo, você pode 
subir na corda o suficiente para que 


ele passe por baixo, então você 
pode guiar Ali Babá para o solo no¬ 
vamente e continuar. Note que é 
possível voltar para baixo também, 
caso necessário. 



Ao atingir o último nível e içar 
as últimas cordas, suba, por qual¬ 
quer uma delas, até o tesouro. As¬ 
sim, você ouvirá Ali Babá pronun¬ 
ciar as palavras mágicas, dando 
acesso ao tesouro (a voz sintetizada 
será reproduzida novamente). Com 
isso, você completou a missão! O 
jogo continua, as fases apresentam 
a mesma "mecânica", mas com ní¬ 
vel de dificuldade crescente a cada 
fase, como ocorre com boa parte 
dos jogos do Atari. As chaves de di¬ 
ficuldade não são utilizadas, nem a 
Game Select. Na verdade, ela tem 
o mesmo efeito da Game Reset. A 
chave Cor/P8cB, curiosamente, ao 
ser colocada na posição "preto e 
branco", deixa os gráficos do bone- 
quinho do Ali Babá, que represen¬ 
tam as vidas de reserva, na base da 
tela, e o placar, no alto da tela, em 
preto-e-branco, porém, o restante 
do jogo continua colorido! Bizarrices 
da BitCorp... 

Os gráficos do jogo são me¬ 
dianos, seguem o mesmo "padrão" 
dos outros jogos da CCE desta série 
(ou seja, seguem o "padrão" da Bi¬ 
tCorp.), é fácil perceber. Por isso, não 
são muito sofisticados, e neste caso 
são meio "quadradões" mesmo. A 
animação de Ali Babá se movendo 
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também não é muito "certinha". O 
som é muito repetitivo, não há mú¬ 
sica de fundo, e, salvo a voz sinte¬ 
tizada, o som do jogo deixa muito 
a desejar. A resposta do joystick é 
um pouco lenta, mas é algo do jogo 
mesmo. A jogabilidade em si é bem 
simples e acaba "enjoando" rápi¬ 
do, lamentavelmente. Uma pena, 
a idéia até que é boa, poderiam 
ter melhorado em alguns aspectos, 
deixaria o jogo mais bacana! 

Este título, por incrível que 
pareça, teve alguns relançamentos, 
por outras empresas, fora a produto¬ 
ra original (BitCorp.). Ele foi lança¬ 
do, náo só aqui no Brasil, por uma 
empresa chamada Zimag (a qual, 
curiosamente, lançou outros jogos 
da BitCorp. com outro nome) com 
o nome alterado - e bem cômico 
até - para "I want my Mommy" ou, 
em português, algo como "Eu quero 
a minha máe!". O jogo é essencial¬ 
mente o mesmo, porém, foi removi¬ 
da a voz sintetizada. Colocou-se no 
lugar uma pequena melodia ao se 
ligar o cartucho, e o gráfico do te¬ 
souro do Ali Babá foi substituído por 
um desenho de uma maçá! E, cla¬ 
ro, a história do jogo foi modificada. 
Nesse, você é Teddy, que precisa ir 
até a sua máe, as cordas sáo agora 
as "escadas mágicas" e as bolas de 
magia sáo os "beijos da mamãe". 
Que fofo, náo? Além deste, o jogo foi 
lançado também com o nome de 
"Apples and Dolls", inclusive lança¬ 
do com este nome por nada menos 
que a própria Polyvox! 

Enfim, se o "Open, Sesame" 
em si náo é lá grande coisa, ao me¬ 
nos traz algumas curiosidades inte¬ 
ressantes! 



ZEPHYR JLX-L 

Froggy Software (Richard Soberka) 
para Apple lie, IIc e IIGS 
Gráficos/Som: 8 
Ação/Controles: ó 

Marcus Vinícius Garrett Chiado 


O ano é 2167. A Terra foi aban¬ 
donada após a Terceira Guer¬ 
ra Mundial e outros mundos foram 
colonizados pelo Homem desde en- 
táo. O jogador, no papel do valente 
Tenente Richard Britain, deve de¬ 
fender a colônia EOR-A5 contra os 
invasores inimigos que ameaçam 
dominar o planeta. Para tanto, há à 
disposiçáo a nave especial Zephyr, 
que dá titulo ao jogo, com a qual 
a solitária missáo deve ser levada a 
cabo. 

Programado pelo francês Ri¬ 
chard Soberka, manjado hacker e 
programador de Apple II daquele 
país, Zephyr deveria ter sido lançado 
no Natal de 1987 - e só náo viu a luz 
do dia porque a softhouse em ques- 
táo, a Froggy Software, encerrou as 
atividades. A fim de que o projeto 
náo ficasse perdido para sempre, a 
Brutal Deluxe Software conversou 
com o autor e resolveu lançá-lo, em 
quantidade limitada, em 2013. O 
produto foi comercializado em um 
pacote com diskette de 5,25" (uma 
face contendo a versáo em Francês, 
a outra contendo a versáo "interna¬ 
cional", isto é, em Inglês) e manual 
bilíngue colorido, tudo acondicio¬ 
nado em uma embalagem do tipo 


ZipLock, comumente usada no fim 
dos anos 70 e início dos 80 quando 
os primeiros programadores, de fun¬ 
do de quintal, resolviam lançar seus 
joguinhos e aplicativos de maneira 
independente. 

Em Zephyr, o jogador dispõe 
de três naves cujas armas sáo dis¬ 
paros laser e cuja missáo é avançar 
pelos setores da colônia, destruindo 
tudo o que vir pela frente. A nave 
pode manobrar para os lados e 
também verticalmente, e deve ser 
reabastecida durante o percurso, 
bastando que se voe através de 
placas gigantes com as inscrições 
"K" (de Kerozene em Inglês); as 
quais sáo tanques de combustível 
que estáo na superfície planetá¬ 
ria. Os inimigos sáo bem variados 
e nem todos podem ser destruídos: 
há veículos, naves, foguetes em 
rampas de lançamento, tanques de 
guerra, tanques de produtos quími¬ 
cos, fábricas, construções e até alie¬ 



nígenas gigantes contra os quais a 
nave pode acabar se chocando. No 
canto superior da tela há alguns in¬ 
dicadores com que o jogador pode 
contar. É possível checar por meio 
deles, por exemplo, a distância per¬ 
corrida, a altitude, o setor (tela), a 
pontuação, a quantidade de naves 
faltantes e a quantidade de com¬ 
bustível que resta. No centro dos in¬ 
dicadores também existe um radar 
que deve ser usado para que se te¬ 
nha idéia do que há pela frente, ele 
é muito útil. 
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JOYSTICK 


Os gráficos, embora mono¬ 
cromáticos, sáo bonitos e variados, 
e foram desenvolvidos na resoluçáo 
do Apple conhecida como DHGR (a 
famosa "Dupla-Alta"), dando idéia 
de tridimensionalidade. Logo de 
cara há uma bela tela de apresen¬ 
tação em que se ouve, numa fala 
sampleada, o título do jogo. Criou- 
se uma bela imagem de fundo que 
retrata o que parece ser uma cida¬ 
de à distância, a qual varia confor¬ 
me o scroll lateral. A jogabilidade 



é muito rápida e, até certo ponto, 
bem confusa. Não se pode tirar os 
olhos da tela, principalmente do 
contador de combustível, que aca¬ 
ba rápido. Falando a verdade, tudo 
acontece rapidamente, a tela logo 
enche de adversários e de disparos, 
a ação é frenética. Se há algo que 
desaponta, porém, é o som simpló¬ 
rio e repetitivo dos disparos e explo¬ 
sões. Eles poderiam ter sido melhor 
elaborados. 

Zephyr parece ser uma curio¬ 
sa mistura de Zaxxon (embora visto 
de frente), Buck Rogers: Planet of 
Zoom e Moonsweeper (do Atari), o 
jogo faz uso da mesma mecânica 
do voe-atire-abasteça. Apesar de 
não agradar a todos, é um dos lan¬ 
çamentos recentes que vieram a 
calhar para os amantes dos micros 
da Apple, uma pena que o produto 
esteja esgotado. 

Dicas: Na dúvida, mantenha sua 
nave na maior altitude possível 


para que possa sobrevoar os obstá¬ 
culos. Não fique parado sempre na 
mesma direção, manobre sempre a 
nave para os lados. 



COPYRIGHT D Y N H MICRO HCHL XXXII 


I D h P E VE ENTER.. 

..THE DUHGEONS OF DhGGORhTHH! 


DUNGEONS OF DAGGORATH ±±±±± 

DynaMicro para TRS-Color e 
compatíveis 
Gráficos/Som: 9 
Ação/Controles: 8 


Robson dos Santos França 

O s jogos eletrônicos podem ser 
vistos como representações de 
uma realidade observada (simula¬ 
dores) ou, como ocorre na maioria 
dos casos, de uma realidade cons¬ 
truída. De toda forma, os criadores 
de jogos trabalham para que essa 
representação tenha certos ele¬ 
mentos com um quê mais realista 
ou mais próximo da nossa reali¬ 
dade. Isso pode ser feito de várias 
maneiras. Por exemplo, podem-se 
criar efeitos sonoros de explosões, 
passos, disparos de armas de fogo 
etc. Esse recurso também pode ser 
utilizado nos gráficos, com o uso de 
imagens fotorealísticas, ilustrações 
feitas por artistas gráficos e o uso de 
gráficos tridimensionais - ou, no me¬ 
lhor caso, que criem uma ilusão de 
perspectiva. 

Um dos consoles clássicos 
especializado em gráficos vetoriais 


chama-se Vectrex. Possuindo uma 
tela de tubo de raios catódicos 
(CRT) dentro de seu próprio gabine¬ 
te, o Vectrex era capaz de renderi- 
zar imagens vetoriais e, com pouco 
esforço, criar o efeito de perspectiva 
ou de profundidade citado ante¬ 
riormente. Para auxiliar nos cálcu¬ 
los matemáticos necessários nessa 
tarefa, o Vectrex contava com um 
microprocessador 6809, projetado 
pela Motorola. 

Uma linha de microcompu¬ 
tadores clássicos que também con¬ 
tava com esse processador era a li¬ 
nha TRS Color, representada aqui no 
Brasil pelos clones Prológica CP 400, 
Codimex, Color 64, Dynacom MX- 
1600, dentre outros. O 6809 possui 
diversos recursos importantes para 
gráficos vetoriais, inclusive uma 
instrução de multiplicação, coisa in- 
comum se comparado com alguns 
dos processadores "rivais" da época, 
como o MOS 6502 e o Zilog Z80. 



Douglas J. Morgan foi o líder 
de desenvolvimento para a Dyna¬ 
Micro de um dos mais desafiadores 
e ousados jogos para os micros da 
linha TRS Color. Dungeons of Da- 
ggorath é um jogo de ação com 
fortes elementos de RPG, um típico 
"dungeon crawler" (explorador de 
masmorras). Seu objetivo é atraves¬ 
sar as masmorras de Daggorath, lu¬ 
tando contra cavaleiros, monstros, 
aranhas e serpentes. Os labirintos 
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ou níveis (cinco ao todo) são intrin¬ 
cados. Para passar de um para o 
outro, por exemplo, há escadas em 
alguns pontos. Antecedendo vários 



jogos desse estilo - como Phantasy 
Star para Master System e Ultima 
Underworld para MS-DOS - o jogo 
conta com gráficos vetoriais para 
desenhar todos os elementos da 
tela. Além disso, apresenta vista em 
primeira pessoa, um conceito relati¬ 
vamente novo na ocasião. 

No entanto, a inovação da 
equipe liderada por Douglas Mor¬ 
gan não parou nos gráficos. Não há 
uma barra de saúde (health bar), 
ao invés disso, o que o jogo apresen¬ 
ta como indicação da saúde (vida) 
do seu personagem é um coração 
batendo. O seu personagem morre 
de ataque cardíaco causado pelo 
nervosismo durante o jogo. Quanto 
mais o jogador se desloca e mais 
inimigos aparecem e atacam, mais 
acelerado o coração fica. Um som 
rítmico acompanha cada batida, o 
que deixa o próprio jogador preocu¬ 
pado; há o aumento da imersão, o 
jogador passa a se sentir cada vez 
mais no interior das masmorras. Ex¬ 
ceto pelos efeitos sonoros dos ata¬ 
ques e do movimento do persona¬ 
gem e dos inimigos, não há outros 
sons, o que confere ao clima uma 
tensão adicional. 

Por outro lado, a jogabilida- 
de de Dungeons of Draggorath está 


mais próxima dos títulos de aven¬ 
tura textuais, como Zork. Não se 
preocupe se você não possui um 
joystick, pois o jogo não necessita 
de um. Ao invés disso, ele aceita 
comandos digitados, como MOVE 
para mover o personagem, TURN 
LEFT para virar à esquerda, PULL 
RIGHT <item> para pegar um item 
com a mão direita, ATTACK RIGHT 
para atacar com o objeto que se en¬ 
contra na mão direita, LOOK para 
observar o ambiente, EXAMINE 
para procurar por itens nas salas da 
masmorra, e assim por diante. Esses 
comandos possuem abreviações (A 
L para atacar com a mão direita, 
por exemplo), que agilizam o con¬ 
trole do jogador. No entanto, o fato 
de ser necessário digitar os coman¬ 
dos, aliado à tensão provocada por 
todo o clima, faz com que a mera 
digitação de caracteres se apresen¬ 
te como um desafio extra e como 
mais um elemento de tensão. 



O segredo para dominar a 
aventura está em balancear os ata¬ 
ques aos inimigos e a movimenta¬ 
ção pelos labirintos, enquanto o jo¬ 
gador usa o escudo para se proteger 
e bebe líquidos de vigor (thews üask) 
espalhados pelas telas, evitando os 
líquidos de penalidade (abye üask) 
para não sofrer danos. Quando a 
força do jogador for inferior ao dano 
sofrido, os batimentos cardíacos fi¬ 
cam acelerados e, ao passarem 
certo limiar, o personagem morre. 


O jogador, então, é agraciado com 
a mensagem: "YET ANOTHER DOES 
NOT RETURN". 

Considerado um dos mais 
elaborados jogos para a linha TRS 
Color, Dungeons of Draggorath não 
é para os fracos e os que se intimi¬ 
dam facilmente. 



BUCK ROGERS SUPER GAME 

Team Pixelboy para ColecoV 
com SuperGame Module 
Gráücos/Som: 9 
Ação/Controles: 7 


Marcus Vinícius Garrett Chiado 


B uck Rogers Super Game é uma 
conversão, para o ColecoVision, 
do arcade Buck Rogers: Planet of 
Zoom, lançado pela SEGA em 1982. 
Um port já havia sido lançado em 
cartucho, é verdade, mas a versão 
aqui analisada é a que foi adap¬ 
tada a partir do microcomputador 
Adam, também da Coleco, para 
que funcionasse com o SuperGame 
Module da OpCode Games (vide a 
Jogos 80 de número 10) em qual¬ 
quer ColecoVision comum. 

No comando de um caça es¬ 
pacial, você é o herói Buck Rogers 
e deve enfrentar hordas de inimigos 
que ameaçam o Planeta Zoom. De- 
ve-se pilotar ora em superfícies pla¬ 
netárias, cheias de discos voadores, 

> 












































JOYSTICK 


torpedos, "Tripeds", tanques e outras 
ameaças, ora no espaço sideral, en¬ 
frentando asteroides, naves, minas 
espaciais e satélites até que, uma 
vez no Planeta Zoom, atinja-se a 
nave de comando invasora para 
que Buck Rogers, se bem sucedido, 
possa escapar por meio do Space 
Warp Tunnel. O gameplay recome¬ 
ça, então, de maneira sucessiva¬ 
mente mais difícil. 

Cada tela apresenta um nú¬ 
mero X de naves/veículos que de¬ 
vem ser destruídos, número esse in¬ 
dicado pelo contador "UFO Count", 
ao passo em que, na parte superior 
do vídeo, outro contador, de tempo, 
decresce. Caso se destruam os inva¬ 
sores antes que o tempo chegue a 
zero, ganha-se um bônus. Somente 
será possível avançar ao próximo 
setor (tela) quando se pulverizar 
a quantidade de inimigos indica¬ 
da - os únicos cuja destruição não 
afeta a contagem são os torpedos 
e os foguetes. Os dez setores, cada 
qual com suas particularidades, 
são respectivamente: First Trench, 
Saucer Battle, Pylon Array, Space 
Mine Field, Second Trench, Lan- 
ding Zone, Asteroid Field, Surface of 
Zoom, Command Ship e Space War 
Tunnel. 

Há duas formas de se utilizar 
o controle do ColecoVision no jogo. 
Há o modo original de comando 
da versão do Adam (que desagra¬ 
dava muita gente) e há o modo 
implementado pela Team Pixelboy, 
empresa que lançou o cartucho, 
com fins de facilitar o gameplay 
e, segundo a empresa, melhorar o 
jogo, deixando os comandos mais 
parecidos com os do arcade. No 
primeiro, o botão direito dispara a 
arma e o botão esquerdo acelera a 
nave quando pressionado continu¬ 
amente, porém, há desaceleração 
quando se solta o botão. No segun¬ 
do, tanto o botão esquerdo quanto 


o direito disparam e a aceleração é 
controlada pelo keypad, sendo que 
o botão 1 acelera e o botão 3 desa¬ 
celera. Particular mente, o segundo 
modo parece mesmo mais cômodo. 
A fim de que se altere para o modo 
Adam, basta que se pressione a 
tecla * (asterisco) na tela em que 
aparece o título do jogo; caso nada 
seja feito, automaticamente o modo 
Team Pixelboy é acionado. Procure 
experimentar ambos, eles trazem 
desafios diferentes - e o nível de difi¬ 
culdade é mesmo alto, preparem-se 
para penar nas primeiras partidas! 



Em termos gráficos, Buck Ro¬ 
gers Super Game é bem melhor que 
o primeiro, isto é, a versão normal 
do ColecoVision. Há mais sortimen¬ 
to de inimigos, há gráficos de fundo/ 
cenários melhor elaborados e, em 
algumas telas, há até side scrolling. 
Além disso, há efeitos sonoros dife¬ 
rentes e um efeito muito bonito de 
explosão da nave do jogador, au¬ 
sente do cartucho comum. Pode-se 
dizer que o nome Super Game não 
existe somente no título, pois pro¬ 
porciona uma nova vida ao game! 
A Team Pixelboy está de parabéns 
também por comercializar um pro¬ 
duto de primeira qualidade: a em¬ 
balagem, o labei, o overlay, o belo 
cartucho translúcido, enfim, é tudo 
muito caprichado. Recomendamos 
este belo jogo para o sistema Cole¬ 
coVision! 
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Marcus Vinícius Garrett Chiado 


E incrível como, de tempos para cá, a tecnologia 
fica obsoleta e se reinventa tão rapidamente, 
quase como se não aproveitássemos direito um 
produto recém comprado. Em termos de games, não 
é diferente, tem-se a impressão de que um console é 
lançado e logo é substituído por um que tenha mais 
memória, mais capacidade gráfica e jogos mais 
complexos. Houve uma época, porém, que as coisas 
não aconteciam tão rapidamente. 

Sobre este tema, o estar obsoleto e a chegada 
do novo, é que trata o documentário britânico "Árca¬ 
de Attack: The Silverball Heroes Vs. Video Invaders", 
produção de 1982 do britânico Mike Wallington, di¬ 
retor e produtor de documentários. Em seus 25 mi¬ 
nutos de duração. Árcade Attack põe frente à frente 
um colecionador de Pinball, Geoff Harvey, e o ga¬ 
roto prodígio Stephen Highfield, mestre do jogo de 
arcade Defender, da Williams, à época em que os 
ditos fliperamas de tela ganhavam popularidade e 
começavam a deixar as velhas mesas da Bally, da 
Gottlieb e da Williams para trás. Em meio aos sons 
sintetizados, às luzes e aos efeitos sonoros, cada qual 
procura, de certa forma, se "defender"; demonstran¬ 
do por A + B as peculiaridades positivas de seus ob¬ 
jetos de desejo: ora o caráter caótico, imprevisível e 
"mágico" do Pinball, ora a "inteligência" regida pelos 
chips de Defender, uma inteligência que seria man¬ 
jada, programada, não caótica. 
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O grande viés do documentário, porém, já 
pode ser percebido nos primeiros minutos de exi¬ 
bição, nas cenas rodadas em um cais da Ingla¬ 
terra - e o destino cruel a que todos os aparelhos 
eletrônicos, inclusos os games, acabam entregues: 
tornar-se obsoletos. A bola da vez, isto é, a batalha 
da vez, contudo, traz a imensa coleção de pinballs 
barulhentos e iluminados versus as novas máquinas 
de diversão eletrônica, os arcades, que chegavam 
para ficar com seus gabinetes verticais igualmente 
iluminados. Homem e menino "digladiam" e ecoam 
as respectivas tecnologias. 

Não ousaremos estragar os fantásticos minutos 
finais do documentário (se é que se pode chamá-lo 
assim, pois há uma mudança brusca na linguagem, 
que se torna metalinguagem), quando os telespec¬ 
tadores poderão esperar por algo parecido com o 
que se vê no filme Tron. 

No fim das contas, a ironia da coisa é que, 
hoje, tanto o Pinball quanto os Arcades, como os co¬ 
nhecemos, estão extintos. 

E quem não tem medo de ficar obsoleto? 


O documentário pode ser visto on-line por meio desta URL: 

http : vuirfirf. garaetrai lers. cora/u ideos/of h7ty/arcade-attack— 
1982—25-nin- 






















































ENTREVISTA: Andy Hopper 



E le é catedrático de Informática e 
diretor do laboratório de computa¬ 
ção da universidade de Cambridge, 
Inglaterra. Além destas credenciais, tam¬ 
bém esteve diretamente envolvido com a 
Acorn Computers e ajudou a desenvolver 
o lendário BBC Micro, além de ter criado a 
Econet, a rede da Acorn. Tivemos a honra 
e o prazer de conversar com Andy Hopper 
após a palestra que ministrou em São Car¬ 
los, interior de SP (vide http ; //LJLJLJ.cl.can. 
3C. 12/ para os slides). Ele bateu um 

papo com a Jogos 80 e revelou detalhes 
sobre projetos dos quais participou, bem 
como das empresas nas quais atuou. 


Entrevista e Tradução: 
Jecel Mattos de Assumpção Jr. 


Jogos 80: Na palestra, o sr. mencionou que 
fundou a Acorn, mas começou a sua própria 
companhia, a Orbis, e esta foi comprada pela 
Acorn. Por favor, comente. 

Andy Hopper: Sim, está certo. Na realidade, eu 
cofundei a Orbis com Hermann Hauser, que era uma 
companhia de redes, e Hermann Hauser cofundou 
a Acorn (na realidade, não era chamada de Acorn, 
era chamada de CPU Limited) com Chris Curry. Elas 
íicavam na mesma sala, no mesmo escritório. Logo 
depois, Hermann e Andy venderam a Orbis para o 
Hermann e o Chris, e Hermann, Andy e Chris eram 
diretores da coisa toda. Em menos de um ano, ou seja, 
dentro de um período curto de tempo, tudo se tornou 
um. Mas, para usar uma expressão americana, eu 
era o terceiro "trouxa". 


J80: A participação do sr., dali em diante, qual 
foi? 

AH: Eu era diretor, era dono de ações e era "diretor 
de pesquisa". Você sabe, eu era o que disse hoje na 
palestra, isto é, fazia aquela ligação do knowhow 
da universidade com os indivíduos - dentro da 
universidade - para o propósito de recrutamento 
e para o propósito de influência. E, como 
reciprocidade, acabamos fazendo muitas doações 
para a universidade e coisas assim. 

J80: A Orbis era voltada às redes, logo o sr. teve 
alguma influência na Econet? 

AH: Sim, eu projetei a Econet da Acorn. Nós tínhamos 
uma rede de alta velocidade, chamada de Anel de 
Cambridge, a 10 Mbps. Vendemos alguns projetos 
na Orbis e o sistema era high end, bem caro. 
Novamente, todo o conhecimento foi transferido 
para alguém... um sistema de rede da Acorn, com 
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servidores de arquivo, redes etc. Ainda me lembro 
de Bill Gates chegando, um dia, e perguntando: "O 
que é isso?". Falamos: "Bill, isso é uma rede!"; ao que 
respondeu: "Muito interessante". E a Econet era para 
tentar fazer algo que funcionasse razoavelmente 
bem e o mais barato possível. Jogamos fora o anel, 
que era muito caro, e adotamos um projeto, ao estilo 
Ethernet, muito simples e que precisava de uns 
poucos transistores para implementá-lo. Assim foi 
como a Econet começou. 

J80: Sobre o chip do BBC Micro? Qual foi seu 
papel? 

AH: Antes de fazer o processador ARM, fizemos coisas 
loucas. A Acorn fez chips usando software de C.A.D. 
que tinha sido desenvolvido e projetado por colegas; 
não só por mim, mas David Wheeler e Maurice Wilkes. 
Usamos software de 
C.A.D. para projetar 
chips, para se ter 
a descrição das 
conexões, para se 
ter um simulador, 
um pacote de 

layout, anotação 
vinda do layout 
dos capacitores, 
capacitâncias das trilhas (para ver se ainda 
funcionaria), esse tipos de coisas. Então, isso tudo 
foi escolhido e usado dentro da Acorn para que se 
projetassem dois chips de vídeo e um para a interface 
serial. Fisicamente, nós ainda nos sentávamos 
no laboratório de computação "debaixo" de um 
contrato da Acorn. Acabou que o BBC Micro tinha 
gráficos melhores do que a competição. A razão 
porque tinha melhores gráficos era, em parte, porque 
a coisa estava implementada num chip. O chip, a 
propósito, foi testado para temperatura no forno da 
minha casa. 

J80: Oh! Isso é fantástico! 

AH: O BBC Micro... Eu o coloquei no meu forno 
e aumentei a temperatura para ver quando ele 
parava de funcionar. 


J80: O primeiro protótipo foi construído com TTLs 
ou ele já tinha um chip próprio? 

AH: Ele já tinha um chip próprio. 

J80: Aquele primeiro protótipo que foi construído 
em uma semana? 

AH: Não, desculpe! Aquele não tinha. Desculpe, o 
que foi construído em uma semana não tinha, não 
tínhamos bem os gráficos. A implementação real 
com todas as características do Modo 0, que era 
o modo de alta resolução, só estava disponível na 
versão com o chip. 

J80: O sr. está falando daquele C.A.D. que foi 
desenvolvido para o projeto do Anel Rápido de 
Cambridge? 

AH: Não era só o 
Anel Rápido de 
Cambridge - era, 
antes, o Anel de 
Cambridge. A 
Acorn pegou as 
ferramentas de 
C. A. D. do laboratório 
de computação e as 
usou. Eles tinham boa ciência da computação de 
modo que a linguagem de descrição de hardware 
era bem genérica. Era, na realidade, uma linguagem 
de programação mesmo. Assim, poderia descrever 
toda espécie de coisas. Não era restrita, era uma 
abordagem bem de ciência da computação, mas 
não estava sendo desenvolvida comercialmente 
de nenhuma maneira. Deveria ter sido, hoje seria 
chamada de Cadence. Como a indústria de C.A.D. 
estava começando, nós decidimos, na Acorn, que 
precisávamos de um conjunto bom de ferramentas. 
Eu convenci Hermann, que era o diretor-gerente, que 
devíamos investir um bom dinheiro para comprar 
as ferramentas. O projeto ARM foi completamente 
baseado nas ferramentas, ferramentas comerciais. 

J80: Da VLSI Technology? 

AH: Está certo. Qudos era uma companhia que 
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“...ainda me lembro de Bill Gates che¬ 
gando, um dia, e perguntando: ‘O que 
é isso?’. Falamos: ‘Bill, isso é uma rede!’; 
ao que respondeu: ‘Muito interessante’...” 









































três de nós começamos; Hermann, eu e um colega 
chamado Haroon Ahmed. E ela usou as ferramentas 
de C.A.D. do laboratório de computação que 
tinham sido licenciadas para a Acorn por uma 
quantia modesta. Usou como a base do produto. O 
problema era... Tentamos fazer coisas em demasia. 
E éramos muito bonzinhos uns com os outros. As 
personalidades funcionavam assim: eu, como 
engenheiro de computação, Hermann, como físico 
com vocação para a inovação, e Haroon Ahmed, 
como um engenheiro voltado para a Física, que 
construía máquinas e-beam - de feixes de elétrons, 
certo? Decidimos. Teríamos o empreendedorismo do 
Hermann, teríamos minhas ferramentas de C.A.D. 
e teríamos as máquinas e-beam do Haroon. Era 
como cinco negócios e não um. Então deveríamos 
ter abandonado o negócio de e-beam, que não 
estava aumentando, era complicado, caro e assim 
por diante. Mas éramos muito bonzinhos uns para 
com os outros. Poderíamos ter sido a Cadence, mas 
não fomos. 

J80: Gostaríamos de saber sobre o financiamento. 
Vimos um programa, “Micro Men", que mostrava 
a Acorn emprestando dinheiro de bancos. 

AH: Sim, emprestamos de bancos e financiamos 
coisas com pessoas... Recebíamos dinheiro para 
entrega futura de produtos e empréstimos bancários. 
Eu não apareci em "Micro Men", pois como disse, 
eu era o terceiro "trouxa". Era essa combinação de 
carreira universitária e industrial, e tem um custo a 
ser pago por isso... Você pode fazer as duas coisas, 
é importante fazer o dobro... Assim, você tem uma 
posição melhor nos dois lados, mas você compromete 
tanto o lado industrial como o acadêmico. 
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J80: O sr. não parecia ser muito favorável ao 
modelo de capital de risco. 

AH: Eu seria se funcionasse. Sou favorável a qualquer 
coisa. 

J80: Isso é algo que não tivemos no Brasil. Todo 
nosso financiamento veio de outras fontes. 

AH: Sim, então, quero dizer que continua até hoje, 
nossas companhias são destruídas e não melhoradas 
com isso. Deixe-me explicar. É a diferença entre a 
Califórnia e Cambridge. Na Califórnia, uma nova 
empresa é o que você poderia chamar de projeto. 
Você se junta com alguns indivíduos, define a 
companhia, trabalham juntos intensamente por 
uns seis meses, um ano, e é um projeto. Se der certo, 
fantástico. Se não der, vocês se separam, você se 
senta ao lado das pessoas seguintes, vocês se 
recombinam. Você pode ter se dado mal aqui, não 
importa, vai em frente. E é fabuloso, uma maneira 
muito eficaz de operar para a Califórnia. Em 
Cambridge temos dinastias. Somos muito voltados 
para a engenharia. Gostamos disso, é nosso talento. 
Então você não se separa e recombina, você se 
casa com alguém, certo? Falando em termos 
de engenheiros. Na situação em que tenho me 
encontrado na maioria dos meus negócios nos 
últimos dez anos, o capital de risco não foi uma boa 
opção. 

J80: Bem, muito obrigado por sua atenção! 

AH: De nada. Muito obrigado por ter escrito para 
mim. 

J80: Muito obrigado por sua palestra. 

AH: Espero que tenha sido útil, 
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Bate-Papo com Howard Scott 
Warshaw sobre a histórica escavação 



E.T. trazido das entranhas da Terra. Foto: Megan Geuss para o site http : //arstechnica. com 


Marcus Vinícius Garrett Chiado 
Carlos Bragatto 


N o dia 26 de Abril, um suposto mito que vinha per¬ 
turbando as mentes de colecionadores de games e 
fãs da Atari desde os anos oitenta foi desvendado. 
Cartuchos do infame jogo E.T. The Extra-Terrestrial, cria¬ 
ção do programador Howard Scott Warshaw para o Atari 
2600, os quais foram enterrados nos anos oitenta - juntos 
de outros títulos - pela Atari em uma tentativa de se livrar 
do "encalhe", começaram a ser desenterrados por uma 
empresa canadense de entretenimento, a Fuel Industries, 
em um evento aberto ao público. A história toda será exi¬ 
bida neste ano, na forma de um documentário produzido 
pelo estúdio Lightbox (e patrocinado pela Microsoft), cuja 
estréia deverá acontecer no famoso evento Comic-Con. 
Posteriormente o vídeo poderá ser visto por meio da rede 
Live, nos consoles Xbox One e Xbox 360, sob o selo Xbox 
Entertainment Studios. 

Não queremos chover no molhado, afinal, diversos 
sites detalharam - com muitas fotos - a famosa escava¬ 
ção que, além de E.T., revelou títulos como Centipede, 
Asteroids, Breakout e Pac-Man. De todo modo, um dos 
fatores mais interessantes do processo foi a presença de 
Howard Warshaw, que acompanhou de perto o evento e 
testemunhou a retirada, do aterro, do primeiro exemplar 
de sua criação encontrado - em estado de conservação 
surpreendente se levados em conta o tempo decorrido e 
as condições de "armazenamento". 


A Jogos 80 bateu um papo com ele para saber o 
que o homem sentiu naquele momento, quais foram suas 
impressões e o que tinha a dizer sobre o mito cujo misté¬ 
rio parece ter sido desvendado. Com a palavra, Howard 
Scott Warshaw! 


Jogos 80: Howard, sabemos que sempre suspeitou de 
que a história do aterro fosse um mito (vejam a Jogos 
80 de número 5), uma farsa. Depois de tudo que foi 
dito e feito, o caso não é um mito afinal. O que tem a 
dizer aos nossos leitores? 

Howard Scott Warshaw: É verdade que sempre duvidei 
da veracidade do mito, porém, nunca fiquei tão feliz da 
vida ao estar errado. O caso é que nunca acreditei no 
mito porque ele não faz sentido. Uma empresa que es¬ 
taria sofrendo financeiramente iria gastar muito dinheiro 
para se livrar de algo presumidamente sem valor? Porém, 
em termos de Atari enquanto empresa, era sempre de se 
esperar algo não convencional, algo incomum. Era uma 
companhia maluca, um lugar de doidos, e justamente o 
não ser convencional é que fez dela um lugar fantástico 
e prazeroso para se trabalhar. 

J80: Alguns sites reportaram que ficou muito emocio¬ 
nado quando encontraram o primeiro cartucho. O 
que passou por sua cabeça na hora? 

HW: Quando os cartuchos foram descobertos, uma horda 
de pessoas se reuniu de forma ensandecida, perplexas, 
ao redor do local da escavação. Todo mundo gritava, as- 
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Conforme informações do sife Alamogordo News, foram desenferrados 
1.377jogos. Esfes nomes perfazem parcialmenfe a contagem do que foi 
achado: 171 cartuchos de E.T., 190 de Centipede, 116 de Defender, 59 
de Missile Command, 99 de Warlords e 53 de Asteroids. Outros títulos de 
Atari 2600 e de Atari 5200, e consoles também foram encontrados. 

O site Polygon informou que, do total, 700 cartuchos serão catalogados, 
avaliados e certificados no Museu de História Espacial do Novo México 
para que possam ser postos à venda ao público. Aproximadamente 100 
serão entregues à Fuel Industries e à Lightbox, responsáveis pela esca¬ 
vação e pelo documentário, e o restante será doado a outros museus 
da região e do país. 

Segundo a mesma reportagem, estimam que ainda haja 700 mil car¬ 
tuchos enterrados no mesmo local, porém, eles devem permanecer 
como tal, ou seja, não serão retirados: “Deixaremos o restante dos jogos 
lá”, disse a prefeita de Alamogordo, Susie Gale a, em entrevista ao refe¬ 
rido site. Joe Lewandowsky, da Operation Consultants, igualmente co¬ 
mentou ao Alamogordo News sobre o porquê de não se retirarem mais 
cartuchos: “Quanto menos material à disposição, mais valioso se torna 
o que temos - e é por isso que não continuamos a perfurar”. 


sobiava, festejava, e o ar estava carregado de excitação, 
alegria e êxtase (e areia!). Então tive um vislumbre, algo 
me ocorreu. A razão pela qual criei jogos na Atari foi en¬ 
treter e alegrar as pessoas, livrando-as das agruras do dia 
a dia. Criei jogos para lhes possibilitar momentos maravi¬ 
lhosos. Naquele dia, no meio do Deserto do Novo México, 
eu fiz exatamente aquilo! Um pedaço de meu trabalho, 
feito há 32 anos, ainda criava momentos especiais! Meu 
coração se enterneceu e fiquei repleto de gratidão. 

J80: Poderia revelar detalhes sobre o documentário 
que estão realizando? 


HW: Trata-se de uma produção de altíssima qualidade, 
feita por profissionais de ponta, sobre um tópico que a 



maioria das pessoas acha que conhece, mas 
que tem muito mais a revelar. Há a promessa 
de que o documentário será esclarecedor e 
contagiante, e que finalmente os fãs poderão 
conhecer, de verdade, o que se passou nos 
bastidores de uma lenda urbana que virou 
mito. 

J80: Howard, ouviu falar do projeto da Ne- 
oComputer (http : //uuu. neocomputer. org / pro- 
jects/et/J para “arrumar” o jogo? Que pensa 
dele? Será que deixaram E.T. mais parecido 
com o que você pretendia à época? 

HW: Não tenho problema algum com a noção 
de que haja problemas de jogabilidade com 
meu E.T. Em outras palavras, tenho os pés no 
chão. Joguei a versão "corrigida" e creio que 
realmente haja uma melhora substancial. Ela 
eliminou, na minha opinião, o maior proble¬ 
ma da versão original: a desorientação do jo¬ 
gador. Honestamente? À época, eu gostaria de poder ter 
tido a chance de programar por mais um ou dois dias 
para que conseguisse corrigir os problemas. De todo 
modo, se eu tivesse gozado de mais alguns dias e corrigi¬ 
do tudo, provavelmente não estaríamos tendo esta con¬ 
versa agora. Obrigado! 

M® 


O site Alamogordo News detalhou os gastos com a 
escavação, que chegaram a 50 mil dólares. Ela foi, 
conforme entrevista dada pela prefeita Susie Galea, 
da cidadede de Alamogordo, mais intensa do que 
se previu: “A escavação teve de ser mais profunda 
do que imaginávamos. Previram que se perfuraria até 
18 pés (5,5 metros), mas tiveram de ir até 30 (9,1 me¬ 
tros)”. 

Os gastos: 

- Perfuração/Equipamento: 20 mil dólares. 

- Engenharia: 12 mil. 

- Gastos com guinchos e reboque: aprox. 10 mil. 

- Segundo aterro (o lixo não pôde ser colocado de 
volta): 8 mil. 

Para saber mais: 

http : Mm\í\. alarao9ordoneus.com/alarao9ordo-neiiis/cij5862460/ 
city-sti 1 l-deciding-what-do-atari-games 
htt-p : //L.JLJLJ. polygon. corii/2014/5/30/5764984/et.-at.ar i-buy-lan- 
df il 1-nuseuim 




Howard Warshaw em entrevista ao 
site IGN. Foto: Howard Warshaw. 
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Novos horizontes para desenvolvimento 

de software para MSX. 


Ricardo Jurczyk Pinheiro 


N a última MSXRio do ano de 2013, um projeto 
que tínhamos conhecimento do desenvol¬ 
vimento finalmente iria ser apresentado. A 
equipe (composta pelo Angelo e o Luciano) traba¬ 
lhava nessa ferramenta há pelo menos 4 anos, e 
finalmente o projeto iria, na sua versão atual, ser 
visto. O sucesso foi imediato. Todos os presentes fi¬ 
caram muito impressionados e com "minhocas na 
cabeça", pensando em tudo que poderia ser desen¬ 
volvido, em termos de aplicativos, e principalmente 
jogos. Então, pensando em apresentar a ferramen¬ 
ta e seus criadores, entrevistei-os para a Jogos 80. 
Nada melhor do que os pais da criança para expli¬ 
car. Então divirtam-se com a conversa! 

Jogos 80: Antes de tudo, falem um pouco de 
vocês. Quem vocês são, de onde vieram, para 
aonde vão... 

Angelo: Chamo-me Angelo Marcelo, tenho 38 anos, 
sou casado e com um filhinho de oito meses. Embora 
tenha cursado Eletrônica durante o segundo grau, 
graças à paixão pelo MSX acabei me graduando 
em Tecnologia de Processamento de Dados pela 
UniverCidade e posteriormente me pós-graduando 
em Análise, Projeto e Gerência de Sistemas pela 
PUC-Rio. Trabalho como Analista/Desenvolvedor 
de sistemas há 15 anos. Gosto de mangá, desenho 
animado, artes marciais e colecionar/jogar em com¬ 
putadores e videogames antigos. O MSX é minha 
paixão, um Gradiente Expert 1.1, que foi meu pri¬ 
meiro micro, quando criança, aos 10 anos de idade 
em 1985. Eu tive no MSX uma boa base para minha 
formação profissional. Além disso, não esqueço os 
laços de amizade que se formaram e se mantêm 


até hoje. Importante dizer que foi graças ao MSX 
que eu e o Luciano nos tornamos amigos na escola 
e essa amizade já tem mais de 25 anos. 

Luciano: Meu nome é Luciano Clemente, tenho 38 
anos, sou casado, tenho duas filhas e moro no Rio 
de Janeiro. Sou analista desenvolvedor graduado 
na UniverCidade e pós-graduado pela PUC-RJ. Tive 
o meu primeiro micro, um MSX Hotbit preto, aos 12 
anos. Comecei a fazer alguns programas, mas sem 
muito contato com informações técnicas, como li¬ 
vros e revistas. Eu usava o MSX principalmente para 
jogar. Eu estudava no mesmo colégio que o Angelo 
e um amigo da classe apresentou-me a ele justa¬ 
mente por causa do MSX. E ele já fazia algumas coi¬ 
sas interessantes em BASIC, apesar da mesma falta 
de informação. Participei de grandes projetos, mas 
este é sem dúvida um dos mais importantes tanto 
pela amizade de 25 anos quanto pela paixão pelo 
MSX! 

J80: O que é o OldBits Dev Studio? Ele é uma IDE, 
um conjunto de bibliotecas, ambos...? 

A/L: Ele é tudo isso e mais o quanto nossa imagi¬ 
nação nos permitiu "viajar na maionese". A ideia é 
criar um ambiente o mais completo possível para 
facilitar o desenvolvimento de novos softwares, tor¬ 
nando o trabalho mais produtivo, e por que não, 
prazeroso? Com isso em mente, podemos dizer que 
a OldBits Dev Studio na verdade é: 

• Uma IDE para desenvolvimento rápido e ágil; 

• Um conjunto de bibliotecas; 

• Um conjunto de ferramentas de auxílio à criação 
de gráficos, áudio etc. 

Por ocasião da elaboração dos requisitos para cons- 
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trução da ferramenta, tentamos pensar em um 
ambiente de desenvolvimento o mais completo 
possível, e voltamos nossa atenção para as atuais 
ferramentas de desenvolvimento, como o NetBe- 
ans, o Microsoft Visual Studio 
e o Eclipse. Com isso, tenta¬ 
mos trazer para o cenário de 
retrocomputação conceitos 
modernos de desenvolvi¬ 
mento de software, mudan¬ 
do paradigmas e trazendo 
agilidade à programação 
sem perder o espírito "OldS- 
chool". Também acrescenta¬ 
mos recursos que são muito 
comuns para os programa¬ 
dores de hoje em dia, mas 
que para o pessoal dos 8 bits 
eram impensáveis naquela 
época. Vamos citar dois dos 
recursos encontrados na Ol- 
dBits Dev Studio para melhor 
compreensão dos benefícios 
que tentamos introduzir com 
esse modelo de desenvolvi¬ 
mento integrado: 


• Code Completion: Recurso 
que ajuda a escrever uma 
instrução, comando ou fun¬ 
ção. Logo, com a digitação 
de apenas algumas letras, 
a IDE "adivinha" o restante, 
completando assim a senten¬ 
ça desejada sem erro. Para 
aqueles que não são desen¬ 
volvedores, isso é parecido 
com o recurso de "predição" 
da digitação dos celulares modernos. 


• Namespace: E um conceito utilizado em lingua¬ 
gens mais modernas, como por exemplo, o Java e o 
C# que agrupam classes ou, no nosso caso, rotinas, 
ajudando não só a manter as bibliotecas de forma 
organizada, mas a evitar confusões de uso equivo¬ 
cado de rotinas, evitando que os nomes "colidam" 
com outras rotinas. Aqui vai um exemplo: 


Old Bits Dev Studio 
Feed teste. 
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nsx.ydp.y9990.pl .sprite.nove( naye> Xj y ) 

Muitos brincam dizendo que os programadores atu¬ 
ais são preguiçosos e alta¬ 
mente dependentes de de¬ 
terminada ferramenta "XYZ", 
mas a verdade é que num 
mundo onde tempo é um 
item cada vez mais escasso, 
somos forçados a cada vez 
mais buscar meios que pou¬ 
pem nosso tempo. A gente 
fica sempre entusiasmado 
quando sai um "demo jogá- 
vel", mas passam-se meses e 
começamos a perceber que 
o projeto foi abandonado por 
desistência dos participan¬ 
tes. Eles não têm mais ânimo 
em dar continuidade a um 
projeto grande, complexo 
e por demasiado longo. Um 
dos objetivos da nossa ferra¬ 
menta é que o desenvolve¬ 
dor não gaste mais dois ou 
três anos para desenvolver 
um jogo. Dessa forma pode¬ 
mos aumentar a quantidade 
de lançamentos e a quan¬ 
tidade de desenvolvedores 
para as mais diversas plata¬ 
formas. 


Coluna 



1 Pioctr». 


OK 


Cancelar 


J80: Qual foi a motivação 
de vocês para fazer essa 
suíte de desenvolvimento? 
Há quanto tempo vocês tra¬ 


balham nela? 


A/L: Nós estávamos na MSXRio'2007, onde nosso 
amigo Márcio Lima de Carvalho nos apresentou ao 
Ricardo Oazem, que tem grandes projetos, entre eles 
a VDU/VSU (módulo com vários VDPs e chip de som 
OPL4) e vimos um potencial produtivo em questão 
de hardware, mas sem muita coisa em software. Isso 
nos levou a iniciar este projeto. A grande motiva- 
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ção foi o Paradoxo de Tostines. Muito se discute nas 
comunidades de Retrocomputação que não vale a 
pena desenvolver novo hardware se não há softwa¬ 
re que os utilize. Contudo, não há estímulo para se 
desenvolver novo software 
se o hardware permane¬ 
cer estagnado. Portanto 
nada se faz e nada será 
feito. Junto a isso, experi¬ 
mentamos o martírio que 
é programar para o MSX 
em um nível mais eleva¬ 
do (ou seria rebaixado?). É 
preciso muito conhecimen¬ 
to técnico para termos um 
desempenho aceitável no 
desenvolvimento de jogos. 

Além disso, jogos mais di¬ 
nâmicos ou aplicativos 
que acessem o hardware 
de forma mais precisa e ou 
controlada requerem um 
enorme esforço, o que está 
muito distante da maio¬ 
ria dos usuários. É muitas 
vezes necessário um co¬ 
nhecimento profundo da 
arquitetura da máquina, 
além de conhecimentos 
avançados de programa¬ 
ção (na maioria das vezes, 

Assembly). Logo, ficou cla¬ 
ro que precisávamos criar 
algo que ajudasse a elimi¬ 
nar ou diminuir boa parte 
dessas barreiras. E com isso 
já se vão uns bons quatro 
anos de desenvolvimento 
da ferramenta e suas bibliotecas, pois foi necessá¬ 
rios adquirir conhecimentos muito específicos, tais 
como: 

• Arquitetura do MSX; 

• Assembly Z80; 

• Construção de Compiladores; 

• Analise léxica, semântica, EBNF, e outros bichos... 


Sem contar nossas próprias responsabilidades com 
família, amigos, trabalho, lazer, etc. Afinal, temos 
uma vida! 

J80: Ele é focado, em 
princípio, em qual micro 
clássico, e quais versões 
desse micro? 

A/L: Inicialmente fizemos 
para a plataforma MSX, 
não apenas por ser a nossa 
favorita, mas por apresen¬ 
tar grande flexibilidade e 
complexidade para tornar 
a ferramenta suficiente¬ 
mente robusta para voos 
mais audaciosos. Não há 
restrição ou foco quanto à 
versão da máquina, bas¬ 
tando que para atender a 
um modelo/versão/confi¬ 
guração haja uma biblio¬ 
teca disponível. 

J80: Quais extensões do 
MSX a ferramenta que 
vocês desenvolveram já 
contempla? 

A/L: Como dissemos, não 
houve foco em um mo¬ 
delo/versão/configuração 
específico. Foi tudo feito 
por questões de oportuni¬ 
dade. Fizemos bibliotecas 
para MSX 1.0, MSX 2.0, e 
até mesmo para Turbo R, 
conforme a necessidade ou oportunidade se apre¬ 
sentassem. Fizemos bibliotecas para explorar recur¬ 
sos novos, como os chips de som OPL4 e chips de 
vídeo como o V9990. Vocês podem ver os vídeos 
das apresentações que aconteceram na última 
MSXRio'2013 e em Jaú, também em 2013. Com isso, 
temos bibliotecas desenvolvidas que funcionam 
para uma grande quantidade de equipamentos, 
mas algumas ainda precisam passar por uma or- 
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ganização, e ainda falta desenvolver muitas outras. 
O desenvolvimento da ferramenta caminha junto 
com o desenvolvimento de novas bibliotecas, bem 
como também pesquisa e experiências com novos 
hardwares. E não podemos falar mais sobre isto. 

J80: No momento, qual é o estado dela? Alfa, 
beta, gama, verde ou madura? Já está disponí¬ 
vel para download? 

A/L: É difícil determinar o estado de algo desse ta¬ 
manho, pois são muitos os detalhes e também mui¬ 
tas as funcionalidades desejadas por nós e que gos¬ 
taríamos de vê-las antes do "lançamento" oficial. 
Contudo, achamos importante informar que faltam 
coisas imprescindíveis para sua plena utilização. 
Coisas tão triviais quanto necessárias que pensa¬ 
mos não ser possível deixar de programar antes de 
permitir o contato da comunidade com a ferramen¬ 
ta. Ou seja... Vai sair um dia, esperem um pouco 
que vai! 

J80: No que ela facilita desenvolver software 
para MSX? 

A/L: A facilidade será usando a IDE e seu conjunto 
de ferramentas, permitindo ao desenvolvedor (usu¬ 
ário) realizar projetos de software com o mínimo de 
conhecimento de arquitetura da máquina. Dessa 
forma, ele estará livre para focar na criação e liber¬ 
to da grande parte dos problemas técnicos para sua 
realização. A IDE manipula bibliotecas (escritas em 
Assembly nativo) de forma tal que o desenvolve¬ 
dor não necessita do conhecimento relativo ao seu 
funcionamento interno, mas somente de seus parâ¬ 
metros de en- 
trada e saída 
(conceito de 
ccáxa preta), 
e que são ex¬ 
portados de 
forma intuiti¬ 
va pela IDE. 
Para aqueles 
que detêm 
conhecimen¬ 
to de progra¬ 


mação as¬ 
sembly e de 
arquitetura 
da máqui¬ 
na, é possí¬ 
vel escrever 
suas próprias 
bibliotecas 
e funções e 
utilizá-las de 
forma trans¬ 
parente em 
seus projetos. 

Estas mesmas bibliotecas que foram desenvolvidas 
por uma pessoa, poderão ser distribuídas para se¬ 
rem utilizadas por toda a comunidade de forma fá¬ 
cil, aumentando o número de softwares desenvolvi¬ 
dos (e concluídos). Esta é a nossa expectativa. 

J80: Então ela é boa para fazer jogos, o que é 
ótimo. Mas, e aplicativos e utilitários? Ela já tem 
alguma extensão para isso? 

A/L: Na verdade, a ferramenta não tem um foco 
específico para jogos. Quer dizer, uma biblioteca 
ou função criada para manipular a SCREEN pode 
ser utilizada tanto para jogos como para um edi¬ 
tor gráfico, exibir os blocos de uma ferramenta de 
desfragmentação de disco, etc. O mesmo vale para 
as bibliotecas de mouse, teclado etc. É importante 
deixar claro que além da possibilidade de se criar 
bibliotecas novas, as já existentes poderão ser es¬ 
tendidas e reformuladas por quem quiser e tiver o 
conhecimento necessário. 

J80: Para desenvolver, nós fazemos como? No 
PC ou direto no MSX? 

A/L: O PC é a máquina utilizada para ro¬ 

dar a ferramenta e gerar, através de cross- 
compiling(compilação cruzada), o código final 
para a máquina alvo. Para nós, o PC é a plataforma 
ideal para ser utilizada nesse tipo de projeto, pois 
ele tem potência bruta de sobra para rodar toda a 
infraestrutura necessária, e a IDE é complexa e pe¬ 
sada. Junte a enorme quantidade de informações 
que são necessárias e mantidas em memória, como 
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ponteiros, tabelas de controle, bibliotecas, e o pró¬ 
prio ambiente gráfico que é o que facilita o desen¬ 
volvimento. Não vimos como seria possível fazer o 
mesmo usando diretamente um MSX, por exemplo. 
Além disso, a IDE permite integração direta com 
emuladores, o que ajuda muito na depuração du¬ 
rante o desenvolvimento. O nível de facilidade e 
funcionalidade que os emuladores oferecem seria 
impossível satisfatoriamente na máquina real. Con¬ 
tudo, a IDE também possui recurso de "deploy" do 
projeto diretamente na máquina real, através da 
placa de rede Obsonet (através da ferramenta Ob- 
soSMB). 

J80: Em quais linguagens de programação po¬ 
demos desenvolver? 

A/L: Inicialmente usaremos um dialeto do Pascal, 
porém a IDE foi feita para suportar outras lingua¬ 
gens desde que o dicionário (ou dialeto) seja cadas¬ 
trado na ferramenta. Temos intenção de cadastrar 
BASIC e C assim que a ferramenta estiver mais está¬ 
vel. Mas na prática não importa qual a linguagem 
será utilizada, pois o código gerado no final será o 
mesmo. 

J80:0 que falta para vocês sentirem-se satisfeitos 
e dizerem: Está feito? 

A/L: Queremos reparar algumas rebarbas que nos 
incomodam e não permitiriam usar plenamente a 
ferramenta. Os demos apresentados recentemente 
nos eventos foram inteiramente desenvolvidos na 
ferramenta. Contudo al- _ 

_ „ r ! CÓDIGO l-ONTE 

gumas lrmrtaçoes nos fo¬ 
ram impostas e gostaría¬ 
mos de eliminá-las antes 
do lançamento. 


J80: Vocês querem ex¬ 
pandir o OldBits Dev 
Studio para outras pla¬ 
taformas, tipo Apple II, 
TRS-Color, Commodore 
64, etc? 


A/L: Esse é outro deta¬ 


lhe que foi pensado desde o início. A ideia é que 
ela seja multiplataforma (várias opções de máqui¬ 
na alvo), multilinguagem e flexível o bastante para 
que se "auto evolua a si mesma"! 

J80: Vocês querem expandir o OldBits Dev Stu¬ 
dio para uso em outros sistemas, como Mac ou 
Linux? É possível? Vocês vão disponibilizar o có¬ 
digo-fonte? 

A/L: A OldBits Dev Studio foi desenvolvida para ro¬ 
dar em Windows, e foi programada em C#. Não 
temos muita familiaridade com outros sistemas ope¬ 
racionais, e quanto à linguagem, o C# era nossa 
linguagem de trabalho do dia-a-dia, então foi uma 
escolha muito natural. Desenvolver em outro siste¬ 
ma operacional e linguagem traria pra nós uma di¬ 
ficuldade a mais no aprendizado desse ambiente 
e com certeza teria aumentado muito mais o tem¬ 
po de construção. Além do que, ficamos muito sa¬ 
tisfeitos com o conjunto Windows/C# que nos deu 
bons resultados em curto tempo. Não temos nesse 
momento interesse em "abrir" o código fonte. Sabe¬ 
mos que ocorrerão reclamações de defensores do 
código aberto, mas é um direito nosso. Temos pla¬ 
nos de cunho pessoal que nos impossibilitam de 
disponibilizar o código fonte, mas isso não é definiti¬ 
vo. Já conversamos algumas vezes a respeito e con¬ 
cluímos que, após alguns objetivos serem atingidos 
(ou não), é sim possível (e desejável, podem acredi¬ 
tar) que a ferramenta seja disponibilizada segundo 
uma licença de código aberto. Mas para não con¬ 
fundir as coisas, todas as bibliotecas estão abertas. E 

mais, não abrir o código 
não significa que não 
possamos ajudar outros 
que estão desenvolven¬ 
do ferramentas. Com isso, 
queremos dizer que espe¬ 
ramos que nossa ferra¬ 
menta seja utilizada, mas 
que a comunidade não 
fique presa e limitada a 
ela, mas que busque ou¬ 
tras e melhores soluções. 
E viva a diversidade de 
software, hardware e 
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ideias! 

J80: Vocês conhecem outros trabalhos, como o 
ZX-Basic Compiler, o compilador C sdcc, confi¬ 
gurações para uso do Eclipse (famosa IDE) para 
desenvolver para micros clássicos, etc? Já pen¬ 
saram em “trocar figurinhas” com eles? 

A/L: Após as apresentações, alguns membros da 
comunidade falaram dessas outras ferramentas e 
fizeram até comparações. Infelizmente a comuni¬ 
dade ainda não teve contato com a ferramenta, 
mas somente a alguns poucos e limitados demos 
produzidos por ela, dificultando a formação de uma 
ideia mais concreta do que ela pode proporcionar. 
Chegamos a olhar a TommyGun, criada para o ZX- 
Spectrum, e foi uma ideia muito boa, mas pelo que 
notamos ainda exige, por parte do desenvolvedor, 
um alto nível de conhecimento de Assembly e ar¬ 
quitetura do micro para utilizá-la. Infelizmente pare¬ 
ce que seu desenvolvimento foi descontinuado. 

J80: A ferramenta é gratuita ou paga? Se for gra¬ 
tuita, de onde podemos baixar? 

A/L: A ferramenta e tudo que a compõe será to¬ 
talmente "di grátis". Nunca tivemos interesse co¬ 
mercial nela. Tudo foi feito por diversão e também 
por busca de conhecimento (mas a diversão vem 
na frente!). Assim que a ferramenta estiver "pronta" 
(nível mínimo aceitável de funcionamento) iremos 
disponibilizar em nosso site, que será divulgado jun¬ 
tamente com a ferramenta. Estamos nos esforçando 
ao máximo para liberá-la o quanto antes. Ninguém 
está mais ansioso que nós por lançá-la. Afinal, até 
aqui foram quatro anos de desenvolvimento. Prefe¬ 
rimos não causar uma falsa expectativa e estragar 
todo o trabalho que tivemos, e que não foi pouco. 
Mas por enquanto, só podemos dizer: Aguardem". 

J80: Expansões para o futuro. O que vocês pre¬ 
tendem acrescentar ao OldBits Dev Studio? 

A/L: Quase todos os dias temos novas ideias, po¬ 
rém estamos nos concentrando para tornar a fer¬ 
ramenta estável para o lançamento. Depois vamos 
focar nas melhorias e na evolução dela, e isso inclui 


trabalhar com outras plataformas. Também preten¬ 
demos prepará-la para ser flexível e auto-suficiente. 
Assim, os próprios usuários poderão expandi-la, 
agregando-lhe funcionalidades, bibliotecas e ferra¬ 
mentas auxiliares, aumentando sua versatilidade e 
uso. 

J80: Por favor, considerações finais de vocês a 
respeito. 

A/L: Estamos muito felizes com o nosso trabalho e 
esperamos que a ferramenta seja útil na criação 
de novos projetos, sejam jogos, aplicativos e quem 
sabe até novas ferramentas de desenvolvimento. 
Esperamos ter contribuído um pouco para alavan¬ 
car novas ideias e integrar mais a comunidade. 
Agradecemos ao interesse de todos da comunida¬ 
de pela OldBits Dev Studio e também pela oportuni¬ 
dade desta entrevista para a Jogos 80. 


Conforme vocês podem ver, o Angelo e o Lu- 
ciano forneceram várias imagens e inclusive um 
pequeno programa feito no Old Bits Dev Studio, a 
título de exemplo. Como um dos expectadores da 
apresentação ocorrida na MSXRio'2013, basta-me 
apenas dizer que ela foi SENSACIONAL. O demo que 
eles apresentaram do R-Type foi feito em apenas 3 
dias, e a mecânica básica do jogo está toda lá, só 
faltam inimigos. As possibilidades são muitas! Meus 
parabéns a ambos pelo tempo dispendido em de¬ 
senvolvimento, e meus votos (e creio eu, de todos) 
de muito sucesso! E eu estou louco para testar essa 
belezinha por aqui. 

Link para o vídeo de demonstração do Oldbits 
DevStudio: https 1 //uuu. youtube. C0M/uatch?Y=TQ7ULZNS9CC 
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